ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイドNetwork Virtualization-Services Edge Design Guide

OL-13637-01-J

Cisco Validated Design

2009/02/23

共有サービスに対するアクセスを集中化することで、すべての VPN にポリシーを実施し、それらを管

理するための共通エリアが提供されます。これは、サービス エッジ機能エリアと呼ばれます。サービ

ス エッジには物理的な意味というよりも論理的な意味があります。特定のネットワーク デザインでは、

ポリシーを実施するポイントは特定のネットワーク エリアに物理的に配置できますが、ネットワーク

全体に分散することもできます。

関連する情報については、次のマニュアルを参照してください。

• 『Network Virtualization—Guest and Partner Access Deployment Guide』：http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/GuestAcc.html

• 『Network Virtualization—Network Admission Control Deployment Guide』：US/docs/solutions/Enterprise/Network_Virtualization/NACDepl.html

• 『Network Virtualization—Path Isolation Design Guide』：http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/PathIsol.html

【注意】シスコ製品をご使用になる前に、安全上の注意

（www.cisco.com/jp/go/safety_warning/）をご確認ください。

本書は、米国シスコシステムズ発行ドキュメントの参考和訳です。

米国サイト掲載ドキュメントとの差異が生じる場合があるため、

正式な内容については米国サイトのドキュメントを参照ください。

また、契約等の記述については、弊社販売パートナー、または、

弊社担当者にご確認ください。

概要

概要ネットワーク バーチャライゼーションという言葉は、共通の物理的な企業ネットワーク インフラスト

ラクチャの上位に位置付けられる、論理的な分離したネットワーク パーティションを構築することを

意味します（図 1を参照）。

図 1 ネットワーク バーチャライゼーション

各パーティションは、他のパーティションから論理的に分離されており、従来の専用の企業ネットワー

クで利用可能だったサービスを同様に提供する必要があります。これは、基本的には、エンド ユーザ

があたかも専用のネットワークに接続されているように、プライバシ、セキュリティ、独立したポリ

シーのセット、サービス レベル、ルーティング決定が提供されることを意味します。

同時に、ネットワーク管理者は、さまざまなユーザ グループのために仮想作業環境の構築と変更が容

易に行え、従来よりも柔軟に業務上の要件の変化へ対応できます。後者については、一元的に実施され

るポリシーによって制御されるセキュリティ ゾーンを作成できることによって実現します。ポリシー

が一元管理されるため、VPN でユーザやサービスを追加または削除する際に、ポリシーの再設定が不

要です。また、グループ全体に影響する新しいポリシーを、一元管理により、VPN 境界に適用できま

す。そのため、企業ネットワーク インフラストラクチャを仮想化すると、複数のネットワークを利用

できるようになりますが、動作上は 1 つのネットワークのように機能するため、関連コストはかかりま

せん（相対的な運営費用の削減）。

ネットワーク バーチャライゼーションは、簡単および複雑なビジネス要因の両方に対応します。簡単

なシナリオとしては、ビジターにインターネット アクセス（ゲスト アクセス）を提供しようとする企

業が考えられます。この場合に厳しく求められるのは、ビジターに外部インターネット アクセスを許

可しながらも、同時に企業の内部リソースおよびサービスへの不正接続は禁止することです。これを実

現するには、ゲストの通信パス全体を処理するための専用の論理「仮想ネットワーク」を用意する必要

があります。パートナー アクセス展開の場合と同様に、インターネット アクセスを、企業内部リソー

スのサブセットへの接続と結合することもできます。

ネットワーク バーチャライゼーションが求められるもうひとつの例は、Network Admission Control（NAC）のポスチャ検証によって検疫されたマシンに専用の論理パーティションを作成するような場合

です。この場合、ネットワークへの修復のためのセグメント内でこれらの装置を確実に分離し、マシン

のクリーニングとパッチ適用が正常に終了するまで修復サーバへのアクセス以外は禁止する必要があり

ます。

2210

35

2ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

概要

複雑なシナリオとしては、それぞれの間で論理的な分離を必要する“カスタマー”に企業ネットワーク

のアクセスを提供するサービス プロバイダーとして振舞う企業 IT 部門が考えられます。将来的には、

同じ論理パーティションに属するユーザは、互いに通信し、専用のネットワーク リソースを共有でき

るようになるでしょう。しかし、グループ間の直接な相互通信の一部は、禁止されるかもしれません。

通常、このカテゴリの展開シナリオとしては、キオスクにネットワークアクセスを提供するリテール

ショップ（たとえば Best Buy、アルバートソンズや Wal-Mart など )やホットスポット プロバイダーが

考えられます。

このような要件を満たすためのエンドツーエンドのネットワーク バーチャライゼーション ソリュー

ションのアーキテクチャは、次の 3 つの論理機能エリアに分類できます（図 2を参照）。

• アクセス コントロール

• パス分離

• サービス エッジ

図 2 ネットワーク バーチャライゼーション：3 つの機能エリア

各エリアは複数の機能を果たし、他の機能エリアと連動して完全に統合されたエンドツーエンドのソ

リューションを提供します。

これらのエリアごとに、個別のデザイン ガイドで詳細を説明します。このマニュアルでは、サービス エッジの要件を扱います。他の 2 つの機能エリアについては、次のマニュアルを参照してください。

• 『Network Virtualization— Access Control Design Guide』： http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/AccContr.html

• 『Network Virtualization—Path Isolation Design Guide』：http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/PathIsol.html

2210

36

GRE

VRF

MPLS

- WAN MAN -

VLAN ACL

3

3

3 VLAN

- -

IP

LWAPP

3ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

サービス エッジ：マニュアルの範囲

企業ネットワークのバーチャライゼーションによって、物理的なインフラストラクチャの上に別の論理

ネットワークを作成できます。これらの仮想ネットワーク（VPN）のデフォルトの状態は、お互いが

完全に隔離されていることで、個別の物理ネットワークをシミュレートしています。

さまざまな VPN が、DHCP、DNS、およびサーバ ファームなどのネットワーク サービスやインター

ネット アクセスなどの特定のサービスを共有する必要がある場合、このデフォルトの動作を変更する

必要があります。

このマニュアルでは、さまざまな VPN 間におけるリソース共有を実現するための別の方法を示しま

す。共有が必要なサービスに加えて、保護されたサービスと保護されていないサービスの違いについて

説明します。このマニュアルでは、保護されたサービス、または保護されていないサービスとしてさま

ざまな VPN が共有するサービスを、アクセス方法に応じて大まかに分類しています。

異なるネットワーク パーティション間でリソースを共有できるようにするさまざまな技術について説

明します。このマニュアルをうまく利用するには、次に注意してください。

• ネットワーク バーチャライゼーション ソリューションとの関連でさまざまな技術について説明し

ます。つまり、これらの技術に関して、前に記載したビジネス上の問題に答えを提供するために有

効性が確認され、ネットワーク バーチャライゼーション プロジェクトの一部として位置づけられ

た詳細事項について説明します。

• このデザイン ガイドのすべての技術が、ビジネス上の諸問題に適合するわけではありません。た

とえば、リソースが特定の仮想ネットワーク専用で共有する必要がまったくないようなシナリオ

（ゲストによるアクセスなど）も考えられます。ここで説明する技術と、特定のビジネス上の諸問

題との関連については、配置に関する次のマニュアルを参照してください。

– 『Network Virtualization—Access Control Design Guide』：http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/AccContr.html

– 『Network Virtualization—Guest and Partner Access Deployment Guide』：http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/GuestAcc.html

– 『Network Virtualization—Network Admission Control Deployment Guide』：US/docs/solutions/Enterprise/Network_Virtualization/NACDepl.html

– 『Network Virtualization—Path Isolation Design Guide』：http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/PathIsol.html

サービス エッジ：マニュアルの範囲ネットワーク バーチャライゼーションのプロセス全体におけるサービス エッジが占める部分では、ポ

リシー実施およびトラフィック操作の大部分が行われます。サービス エッジを導入する前に、このマ

ニュアルで説明されている方法のどれを実施するのか、およびそれらの方法を選択する場合のトレード

オフは何かについて完全に理解しておくことが重要です。また、全体的なネットワーク 適化プロセス

に役立つアプリケーションおよび関連するトラフィックの流れをお客様が理解しておくことも重要で

す。

このマニュアルでは、次の内容を達成することを目的としています。

• 保護されていないアクセスと保護されているアクセスの 2 つのアクセス方法を区別しながら、別々

の論理パーティション間でサービスを共有できるようにする方法についてのガイドラインを提供し

ます。

• サービス エッジ機能を提供するうえでのサービス バーチャライゼーションの重要性を Cisco Firewall Services Module （FWSM）の観点から説明します。

• Unified Communication （UC）アプリケーション（音声、ビデオ）を仮想化されたネットワーク

環境に統合するための 初の技術的オプションを紹介します。このソリューションの範囲は、当初

はキャンパス配置に限定されており、ネットワーク内の共有サービス エリアの概念を利用して UC

4ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

サービス エッジ：マニュアルの範囲

サービス（Cisco Call Manager、TFTP サーバなど）を配置します。仮想ネットワークが別々に分

かれている状況で配置されているネットワーク エンティティ（IP 電話、PC など）は、これらの

サービスにアクセスする必要があります。

• このマニュアルでは、さまざまな技術エリアについて扱っていますが、異なる VPN における重複

する IP アドレスの使用については現時点では説明していません（IP アドレスの重複については将

来的に扱われる可能性があります）。重複する IP アドレスの使用は、ネットワーク インフラスト

ラクチャの運用および管理面でお客様のネットワークに運用上影響が及んでしまうので、通常は推

奨されません。アドレスの重複が避けられないシナリオ（M&A など）においてだけ、使用するよ

うにしてください。

（注） これ以降、このマニュアルの中では、仮想ネットワーク（VPN）と VRF という用語は互換的に使用さ

れます。その中で、これらの用語はすべて、共有の物理ネットワーク インフラストラクチャ上に配置

された論理パーティションを指します。

このマニュアルで説明するサービス エッジ機能は、さまざまなネットワーク エンティティに差別化さ

れたアクセスを提供するために実装されたアクセス コントロール方式や、パス分離用に実装された技

術的な代替方法から独立しているということを強調することも重要です。これは、エンドツーエンドの

ソリューションを提供するために、3 つの機能エリア（アクセス コントロール、パス分離、およびサー

ビス エッジ）を独立して配置し、お互いに連動するようなソリューション フレームワークを作成する

という考えに一致します。

また、ネットワーク インフラストラクチャを仮想化する主要な利点のうちの 1 つは、さまざまな仮想

ネットワーク間に柔軟なインターフェイスを作成できることです。これにより、VPN 間の通信を提供

したり、特定のリソース セットへのアクセスを共有したりできます。

後に、導入の観点から考えると、サービス エッジは物理的なエンティティというよりは、論理的で

抽象的なエンティティと言えます。サービス エッジ機能は、データセンター、インターネット エッジ、

キャンパス コアに接続された専用サービス ブロックなどの企業ネットワークの異なるエリアに物理的

に配置できます。また、この機能を複数の物理的な場所に配置することで、ソリューションの全体的な

ハイ アベイラビリティを増大させることもできます。このマニュアルとの関連で、サイト内部および

サイト間両方のデザインについて説明します。

保護されていないサービス アクセス

保護されていないサービス アクセスとは、トラフィックにいかなる種類のセキュリティ チェックを加

えることなく、共有サービスとの通信を許可するということを意味します。保護されていないサービス

は、サービスと要求ホスト間にポリシー実施ポイントがない状態でも、1 つ以上の VPN から到達可能

です。そのため、保護されていないサービスは、中央のロケーションへトラフィックのヘアピニングを

強制することなく（この強制は、むしろ保護されたアクセスに使用される一般的なモデルです）、さま

ざまな VPN のルーティング テーブルにある 適なパス ルートに従って通常は実行されます。

保護されていないサービス アクセスを実装する技術ソリューションとは、定義されたそれぞれの VPN に結び付いたルーティング テーブル間でプレフィクスをリークすることにあります。これらの論理

パーティションのすべては、個別の物理ネットワークを模倣目的ですが、実際は共通の基本インフラス

トラクチャ上に配置されており、これによりネットワーク間で通信チャネルを開くためのいくつかのメ

カニズムを利用できます。図 3 は、上記の概念図を示します。

5ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

サービス エッジ：マニュアルの範囲

図 3 保護されていないサービス アクセス

この技術オプションは、その性質のために本質的に安全でなく、VPN 間に好ましくない裏口が開かれ

てしまうことを避けるために慎重に導入する必要があります。このことは、ピアツーピア（VPN 間）

接続を提供するためにルート リークを使用するのではなく、異なる VPN 間に中継ゾーンを提供するこ

となくこれらの VPN と通信できる「エクストラネット VPN」の作成に制限する必要があるということ

を意味します。保護されていないサービス共有は、制限された方法で導入することを推奨します。たと

えば、保護が必要な他の共有サービスへのアクセスを制御するのに使用されているファイアウォールへ

不要な負荷をかけることなく、さまざまな VPN へ DHCP または DNS サービスへのアクセスを提供す

ることなどが挙げられます。

保護されたサービス アクセス

保護されたサービスは、特定のセキュリティ ポリシーが実施されて初めて、VPN からアクセスできる

必要があります。管理可能な方法で必要なセキュリティ ポリシーを実施するには、サービスへのアク

セスがポリシー実施ポイントを通過する必要があります。そのため、サービスに到達するすべてのトラ

フィックは、共通のポリシー実施ポイントを通過するようにルーティングされる必要があります。その

結果、要求ホストとサービス間のルーティングは、 適とは言えない状態になる可能性があります。た

だし、このことは、共有サービス自体が VPN の一部であるような非常に特別なシナリオにおいてだけ

当てはまることです。一般的には、保護が必要な共有サービスは、 適なアクセスを提供するように中

央に配置されています。

保護されたサービスの例には、サーバ ファームやインターネットが含まれます。インターネットにア

クセスする場合、VPN からサービスへのアクセスを制御する必要があるだけでなく、サービス エリア

から VPN に対して開始されたすべてのアクセスを制御することも非常に重要です。理想としては、

VPN 内部から通信が開始されない限り、インターネットから VPN へのアクセスは行われないようにす

る必要があるので、サービス エリアから VPN 内部へアクセスすることは通常は禁止されています。

制御された方法によって VPN 間でお互いに通信する必要がある場合は、VPN 境界におけるポリシーを

変更してそのようなアクセスを可能にできます。この特別な VPN 間接続の用途では、VPN 内部に対し

て外部から通信が開始できるようにポリシーを開く必要があります。

アーキテクチャの観点から、保護されたサービス アクセスを提供できるようにするデザインを図 4 で示します。

RedVPN

GreenVPNYellow

VPN22

6245

6ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

サービス エッジ：マニュアルの範囲

図 4 保護されたサービス エッジ

前述のように、定義された各仮想ネットワークでは、セキュリティ デバイス（通常はファイアウォー

ル）がフロントエンドになっており、インバウンドとアウトバウンドの両方向で許可される通信の種類

を厳密に制御できます。VPN ごとに別々のファイアウォールを使用することで、仮想ネットワークご

とに個別にセキュリティ ポリシーの適用および管理を行うことができます。この理由から、この配置

モデルを使用することを推奨します。この後のセクションでさらに説明するように、Cisco FWSM および Cisco ASA の両方で利用可能なファイアウォール サービスのバーチャライゼーションによって、

各論理パーティションに専用の仮想ファイアウォール インスタンス（通常は名前付きコンテキスト）

を使用できます。

フュージョン ルータとは、ソリューションの頭脳と考えられるもので、各 VPN およびリソースの共有

プール間、さらには、個別の VPN 間のトラフィックを適切にルーティングする役割を担っています。

リソースの共有プールが、実際はどのように専用 VPN の一部としても配置可能であるかを知ることは

役に立ちます。フュージョン ルータは、通常、静的ルーティング設定またはルーティング ピアリング

のいずれかを通じて VPN 内部で利用可能なプレフィクスを認識しています。サービス エッジの導入の

詳細な説明では、選択されたプロトコルが、採用されたパス隔離方法およびファイアウォール設定（ト

ランスペアレント モードまたはルーテッド モード）にどのように依存するかが明らかにされます。

フュージョン ルータ機能は、次の異なる 2 つ方法で導入できます。

1. 物理的に別個のルータ（またはレイヤ 3 スイッチ）をこの機能専用にする。

2. この目的のために特定の VRF を使用するように定義する。

これらの 2 つのオプションの区別によって、このマニュアル内でデュアル ティア実装とシングル ティ

ア実装と呼ばれる 2 つの異なるデザインが導かれます。

後に、共有サービスという概念は、配置が異なる場合は、別の意味を持つ場合があります。共有サー

ビスの一般的な例としては、次が挙げられます。

• サーバ ファーム

• インターネット全体

RedVPN

GreenVPN

YellowVPN

2262

46

7ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

• 企業ネットワークの仮想化されていない部分（つまり「グローバル テーブル」）

保護されていない共有サービスの導入保護されていない共有サービスを導入するには、異なる VPN 間で一定の形式のルート リークを導入す

る必要があります。この種類の構成の詳細については、次のセクションで説明します。

VRF 間のルート リーク

別々の VRF 間でルート リークを実行する基本要素は、BGP の route-target 属性です。そのため、この

メカニズムを利用するたびに BGP を有効にする必要があります。選択したパス分離方法によっては、

BGP が各 VPN の内部にルーティング機能を実装するために導入されたコントロール プレーン プロト

コルではない場合があります。パス分離のマニュアルでは、MPLS VPN 構成用に VPN ルートを交換

するために、通常どのように BGP を配置するかについて説明しています。同時に、ネットワーク間で VRF-Lite がエンドツーエンドで利用されるようなシナリオでは、定義された各 VRF 用のコントロー

ル プロトコルは、グローバル テーブル内にすでに配置された IGP （EIGRP または OSPF）と通常同じ

ものです。

（注） 異なるパス分離方法の詳細については、

http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/PathIsol.html を参照し

てください。

上記のような理由から、VRF 間でルート リークを実行するのに BGP が使用されるような 2 つの主要

なシナリオを区別できます。

• マルチデバイスの配置：この場合、通常、MPLS VPN がパス分離方法として選択され、MP-BGP が定義された PE デバイス間で VPN ルートを交換するのに利用されるコントロール プロトコルで

す（図 5 を参照）。

8ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

図 5 保護されていないアクセス：マルチデバイスの配置

• シングルデバイスの配置：これらの配置では、パス分離機能を提供するのに通常 VRF-Lite が利用

され、BGP はコントロール プレーンに使用されません（この機能は、各 VPN が定義された状況

で実行中の IGP によって実行されます）。その結果、通常 BGP は、外部デバイスとの BGP 隣接関

係の確立を要求することなく、ルート リークが実行される必要があるデバイスでだけ、ローカル

で有効化されます。この概念を図 6 に示します。

Si

PC Red PC Green

PE2PE1

PE3

MP-BGPMP-BGP

2262

47

9ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

図 6 保護されていないアクセス：シングルデバイスの配置

次の 2 つのセクションでは、マルチデバイス モデルとシングルデバイス モデルの両方を配置するのに

必要な設定手順について明らかにします。

マルチデバイス モデルの設定

次で説明する設定手順は、図 7で示す特定の例を参考にしています。

PC Red PC Green

IGPIGP

BGP

2262

48

10ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

図 7 マルチデバイスの配置例

このシナリオでは、 下部の PE1 および PE2 デバイスに接続された Red と Green のユーザ間で PE3 デバイスに直接接続されているサーバを共有する必要があります。これは、Red と Green 間の仮想

ネットワークの論理的な分離を損なうことなくこれを実現する必要があります。

• 初期条件：共有リソースの IP プレフィクスは、共有 VRF との関連で PE3 上でだけ知られており、

PE1 および PE2 の Red と Green の VRF では知られていません。

PE3PE1#sh ip route vrf Shared 10.138.32.0Routing entry for 10.138.32.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via eigrp 100 Routing Descriptor Blocks: * directly connected, via Vlan32 Route metric is 0, traffic share count is 1PE1PE2#sh ip route vrf Red 10.138.32.0% Subnet not in tablePE2PE3#sh ip route vrf Green 10.138.32.0% Subnet not in table

• 3 つのデバイス上の設定が適切に変更され、共有プレフィクスのルートが Red と Green の VRF ルーティング テーブルにリークできるようになります。

1. 共有 IP プレフィクスをエクスポートし、iBGP ネイバー デバイスから学習した Red と Green のプレフィクスを BGP テーブルにインポートするための route-target 属性を PE3 上で設定し

ます。

PE3ip vrf Shared

Si

10.138.32.0/24

Red 10.137.12.0/24

Green 10.137.23.0/24

PE2PE1

PE3

MP-BGPMP-BGP

2262

49

11ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

rd 3:3 route-target export 300:300 route-target import 100:100 route-target import 200:200

2. Red の IP プレフィクスをエクスポートし、PE3 から学習した共有プレフィクスを BGP テーブ

ルにインポートするための route-target 属性を PE1 上で設定します。

PE1ip vrf Red rd 1:1 route-target export 100:100 route-target import 300:300 route-target import 100:100

3. Green の IP プレフィクスをエクスポートし、PE3 から学習した共有プレフィクスを BGP テー

ブルにインポートするための route-target 属性を PE2 上で設定します。

PE2ip vrf Green rd 2:2 route-target export 200:200 route-target import 300:300 route-target import 200:200

（注） PE1 と PE2 の両方の設定例（100:100 および 200:200 をインポート）の中の 後の route-target コマンドは、共有サービスへのアクセスを提供するには必要ありませんが、各 VRF 内で any-to-any 接続を提供するのに通常使用されるので、上記でも示されています。

• 設定が実施されると、共有プレフィクスが Red および Green VRF 内で学習されるようになった

（および「直接接続」と表示されるようになった）ことを確認できます。同時に、共有 VRF 内に Red と Green のサブセットが注入されます。

PE1PE1#sh ip route vrf Red 10.138.32.0Routing entry for 10.138.32.0/24 Known via "bgp 100", distance 200, metric 0, type internal Last update from 192.168.100.100 00:29:47 ago Routing Descriptor Blocks: * 192.168.100.100 (Default-IP-Routing-Table), from 192.168.100.100, 00:29:47 ago Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: 18 MPLS Flags: MPLS Required

PE2PE2#sh ip route vrf Green 10.138.32.0Routing entry for 10.138.32.0/24 Known via "bgp 100", distance 200, metric 0, type internal Last update from 192.168.100.100 00:30:35 ago Routing Descriptor Blocks: * 192.168.100.100 (Default-IP-Routing-Table), from 192.168.100.100, 00:30:35 ago Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: 18 MPLS Flags: MPLS Required

PE3

12ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

PE3#sh ip route vrf Shared 10.137.12.0Routing entry for 10.137.12.0/24 Known via "bgp 100", distance 200, metric 0, type internal Last update from 192.168.100.1 00:31:51 ago Routing Descriptor Blocks: * 192.168.100.1 (Default-IP-Routing-Table), from 192.168.100.1, 00:31:51 ago Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: 16 MPLS Flags: MPLS RequiredPE3#sh ip route vrf Shared 10.137.23.0 Routing entry for 10.137.23.0/24 Known via "bgp 100", distance 200, metric 0, type internal Last update from 192.168.100.2 00:31:59 ago Routing Descriptor Blocks: * 192.168.100.2 (Default-IP-Routing-Table), from 192.168.100.2, 00:31:59 ago Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: 17 MPLS Flags: MPLS Required

• 上記の設定手順の結果、Red と Green の VRF のルーティング テーブルには、共有サービスの IP サブネットのルートを含むようになります（逆の場合も同じ）。ただし、共有 VRF は、VPN 間の

通過エリアとしては機能せず、Red と Green の仮想ネットワーク間では望ましい論理的な分離が保

持されます。この動作は、iBGP の非推移的な性質によるものです。この概念を明確にするため

に、共有 VRF の route-target 設定を再度次に示します。

ip vrf Shared rd 3:3 route-target export 300:300 route-target import 100:100 route-target import 200:200

Red と Green のルートが（route-target import コマンドによって）共有 VRF テーブルにインポー

トされ、その結果、BGP の非推移的な性質のために、それらのルートは（route-target export コマンドを使用して）再度エクスポートされません。その他の場合は、ルートはリモート PE（PE1 および PE2） にある Red と Green の VRF にインポートされ、これらの仮想ネットワーク間の論理

的な分離が切断されます。

この BGP の動作が含むもう 1 つの意味は、特定の物理ルータ上の VRF にルートをインポートして

も、同じ VRF が拡張された他のデバイスのルーティング テーブルにはこれらのルートが入力され

ないという事実です。たとえば、図 8 に示すように、Red の VRF が PE2 デバイス上でも定義され

たとします。

13ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

図 8 MP-iBGP の非推移的な性質

共有 IP プレフィクスが PE1 デバイス上の Red の VRF にインポートされた（前述の設定手順に基

づく）という事実があったとしても、PE2 上の Red の VRF ルーティング テーブルで同じ情報は利

用できません。利用できるようにするには、次に示すように PE1 に適用されたのと同じ route-target 設定を PE2 上に追加する必要があります。

PE2ip vrf Red rd 1:1 route-target export 100:100 route-target import 300:300

シングルデバイス モデルの設定

次で説明する設定手順は、図 9 で示す例を参考にしています。

Si

PC Red PC Green PC Red

PE2PE1

PE3

MP-BGPMP-BGP

2262

50

14ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

図 9 シングルデバイス モデルの例

デザインの目的は、マルチデバイス モデルの中で説明したものと同一です。つまり、Red と Green のユーザ両方がそれぞれの間の論理的な分離を失うことなく、共有サービスにアクセスできるようにする

ことです。

• 初期条件：共有リソースの IP プレフィクスは、共有 VRF との関連で R1 上でだけ知られており、

ルータ R2 および R3 の Red と Green の VRF では知られていません。

R1R1#sh ip route vrf Shared 10.138.32.0Routing entry for 10.138.32.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via eigrp 100 Routing Descriptor Blocks: * directly connected, via Vlan32 Route metric is 0, traffic share count is 1

R2R2#sh ip route vrf Red 10.138.32.0% Subnet not in table

R3R3#sh ip route vrf Green 10.138.32.0% Subnet not in table

10.138.32.0/24

Red 10.137.12.0/24

Green 10.137.23.0/24

R1

R3R2

IGPIGP

BGP

2262

51

15ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

• ローカル ルートのリークは、リソースが直接接続されているデバイス上に配置されます（この例

では R1）。初めの想定では、VRF-Lite の配置には、シングル プラットフォームのアプローチ

（ルーティング プロトコルとして IGP が使用され、MP-BGP は使用されない）が使用されるとい

うことだったので、次の設定手順を実行する必要があります。

1. VRF 用に route-target パラメータを設定します。共有 IP プレフィクスを共有 VRF からエクス

ポートし、Red と Green のユーザ VRF にインポートする必要があります。同時に、Red と Green の VRF からエクスポートされたユーザ サブネットを共有 VRF にインポートして、双

方向の接続ができるようにする必要があります。

R1ip vrf Red rd 1:1 route-target export 100:100 route-target import 300:300!ip vrf Green rd 2:2 route-target export 200:200 route-target import 300:300!ip vrf Shared rd 3:3 route-target export 300:300 route-target import 200:200 route-target import 100:100

2. route-target 設定を利用してプレフィクスの交換を起動するように BGP プロセスを有効にしま

す。この場合、プロセスにはローカル機能だけが含まれるので、BGP 設定の中でネイバー関

係を指定する必要がないことに注意してください。また、route-map 文をオプションで使用す

ると、異なるルーティング テーブル間でリークされた IP プレフィクスをより強力に制御でき

ます。

R1access-list 1 permit 10.138.32.0 0.0.0.255access-list 2 permit 10.137.12.0 0.0.0.255access-list 3 permit 10.137.23.0 0.0.0.255!route-map Allowed_Green_Users permit 10 match ip address 3!route-map Allowed_Red_Users permit 10 match ip address 2!route-map Shared_Services permit 10 match ip address 1

EIGRP 特有の設定

router bgp 100 no synchronization bgp log-neighbor-changes no auto-summary ! address-family ipv4 vrf Shared redistribute connected route-map Shared_Services no synchronization exit-address-family ! address-family ipv4 vrf Green redistribute eigrp 100 route-map Allowed_Green_Users

16ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

no synchronization exit-address-family ! address-family ipv4 vrf Red redistribute eigrp 100 route-map Allowed_Red_Users no synchronization exit-address-family

OSPF 特有の設定

router bgp 100 no synchronization bgp log-neighbor-changes no auto-summary ! address-family ipv4 vrf Shared redistribute connected route-map Shared_Services no synchronization exit-address-family ! address-family ipv4 vrf Green redistribute ospf 2 route-map Allowed_Green_Users no synchronization exit-address-family ! address-family ipv4 vrf Red redistribute ospf 1 route-map Allowed_Red_Users no synchronization exit-address-family

共有サービスへアクセスする必要のあるユーザ サブネット（VRF Red と Green 内）は、サービス

（この例では EIGRP または OSPF）を学習するのに使用された IGP を再分配することによって、

代わりに BGP に注入されます。この例では、ルート リークが実行されるレイヤ 3 デバイスに共有

サービスが直接接続されるので、このサービスのプレフィクスは、redistribute connected コマン

ドを使用して BGP に注入されます。サービスが代わりに別のレイヤ 3 デバイスに接続される場合

は、ユーザ サブネットの場合と同様に、サービスを学習するのに使用された IGP を再分配するこ

とで、BGP に注入される場合があります。

（注） route-map が設定されなかった場合は、 終的に Red と Green のすべての VRF プレフィクス

が共有 VRF ルーティング テーブルにリークされる結果となります。予想されるように、これ

によって Red と Green の VPN 間の論理的な分離が損なわれることはないことに注意してくだ

さい。

• 設定が実施されると、共有プレフィクスが Red および Green VRF ルーティング テーブル内に注入

された（および「直接接続」と表示されるようになった）ことを確認できます。同時に、共有 VRF ルーティング テーブル内に Red と Green のサブセットが注入されます。

R1R1#sh ip route vrf Red 10.138.32.0Routing entry for 10.138.32.0/24 Known via "bgp 100", distance 20, metric 0 (connected, via interface), type external Redistributing via eigrp 100, bgp 100 Routing Descriptor Blocks: * directly connected, via Vlan32 Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: none

17ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護されていない共有サービスの導入

R1#sh ip route vrf Green 10.138.32.0Routing entry for 10.138.32.0/24 Known via "bgp 100", distance 20, metric 0 (connected, via interface), type external Redistributing via eigrp 100, bgp 100 Routing Descriptor Blocks: * directly connected, via Vlan32 Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: none

R1#sh ip route vrf Shared 10.137.12.0Routing entry for 10.137.12.0/24 Known via "bgp 100", distance 20, metric 3840, type external Last update from 10.122.15.18 on GigabitEthernet1/3.412, 00:57:13 ago Routing Descriptor Blocks: * 10.122.15.18 (Red), from 0.0.0.0, 00:57:13 ago, via GigabitEthernet1/3.412 Route metric is 3840, traffic share count is 1 AS Hops 0 MPLS label: none

R1#sh ip route vrf Shared 10.137.23.0Routing entry for 10.137.23.0/24 Known via "bgp 100", distance 20, metric 3840, type external Last update from 10.122.25.18 on GigabitEthernet1/3.422, 00:57:18 ago Routing Descriptor Blocks: * 10.122.25.18 (Green), from 0.0.0.0, 00:57:18 ago, via GigabitEthernet1/3.422 Route metric is 3840, traffic share count is 1 AS Hops 0 MPLS label: none

ただし、この時点でも Red と Green のユーザおよび共有リソース間の通信は実現しません。理由

としては、共有 IP プレフィクスが Red と Green の VRF ルーティング テーブルにリークされてい

ますが、R1 デバイスではローカルだけにリークされているためです。R2 および R3 のルーティン

グ テーブルには、いまだにその情報は含まれません。共有プレフィクスを R2 と R3 に伝播するに

は、そのサブネットをネットワーク全体で Red と Green の VRF のエンドツーエンド用にコント

ロール プレーンとして使用される IGP に通知する必要があります。これは、次の設定例で示すよ

うに、R1 上で共有プレフィクスを BGP から IGP に再分配することで実現します。

EIGRP 特有の設定

router eigrp 100 address-family ipv4 vrf Green redistribute bgp 100 metric 100000 1 255 1 1500! address-family ipv4 vrf Red redistribute bgp 100 metric 100000 1 255 1 1500

OSPF 特有の設定

router ospf 1 vrf Red redistribute bgp 100 subnets!Router ospf 2 vrf Green redistribute bgp 100 subnets

この時点で、R1 と R2 の両方で共有プレフィクスが IGP 経由でどのように学習されたかを確認で

きます。この学習により、クライアントとサーバ間の通信が正常に行われます（次の例は、

EIGRP 配置で有効です）。

R2R2#sh ip route vrf Red 10.138.32.0Routing entry for 10.138.32.0/24

18ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

Known via "eigrp 100", distance 90, metric 3840, type internal Redistributing via eigrp 100 Last update from 10.137.11.7 on GigabitEthernet5/2.612, 00:06:06 ago Routing Descriptor Blocks: * 10.137.11.7, from 10.137.11.7, 00:06:06 ago, via GigabitEthernet5/2.612 Route metric is 3840, traffic share count is 1 Total delay is 50 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 4

R3R3#sh ip route vrf Green 10.138.32.0Routing entry for 10.138.32.0/24 Known via "eigrp 100", distance 90, metric 3840, type internal Redistributing via eigrp 100 Last update from 10.137.21.11 on Vlan123, 00:02:18 ago Routing Descriptor Blocks: * 10.137.21.11, from 10.137.21.11, 00:02:18 ago, via Vlan123 Route metric is 3840, traffic share count is 1 Total delay is 50 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 4

• 上記の設定手順では、 終的に、サブネット 10.137.12.0 （VRF Red 内）および 10.137.23.0 （VRF Green 内）に属するユーザだけが双方向の接続を経験する、または使用できる結果となりま

す。共有サービスの IP プレフィクスは、VRF Red と Green が配置されているすべてのレイヤ 3 デバイスに分配されます。これにより、Red と Green の VRF のユーザ部分がすべて R1 上の共有サ

ブネットに到達できるようになります。ただし、リターン トラフィックは、ユーザ プレフィクス

を BGP に再分配する際に route-map を使用した結果、上記の 2 つのサブネットに限定されていま

す。

共有リソースへのアクセスが「保護されていない」と定義されている場合でも、ACL を適用する

ことでさらに制限できます。たとえば、共有サブネットが VLAN 32 経由で直接接続されていると

いう事実を踏まえると、次の設定は、VRF Red 内の 10.137.12.0 サブネットに含まれるユーザにだ

け接続が制限されます。

access-list 133 permit ip 10.137.12.0 0.0.0.255 any!interface Vlan32 ip vrf forwarding Shared ip address 10.138.32.3 255.255.255.0 ip access-group 133 out

運用上の観点からは、これには明らかにより高度な設定と保守が必要ですが、この設定は中央のロ

ケーションで適用されるという事実によって利益が得られます（従来の分散 ACL によるアプロー

チとの比較で）。

保護された共有サービスの導入共有サービスへの保護されたアクセス（再度、図 10 を参照）について説明する場合、デザインに関す

るいくつかの変数を考慮する必要があります。これらは、配置された特定のソリューションに影響しま

す。

19ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 10 保護されたサービス エッジ

• 共有サービスの定義：さまざまな配置の中で、インターネットは、異なる仮想ネットワーク間で共

有する必要のある一般的なリソースを表します。その他のシナリオでは、特定のサービス（例とし

ては Call Manager）が共有リソースを表す場合があります。また、可能性としては少ないのです

が、グローバル テーブル全体を、すべての仮想ネットワークを潜在的に接続できる共有サービス

として考えることもできます。

• 各仮想ネットワークのフロント エンドとして機能するセキュリティ デバイス：これは、通常は

ファイアウォール デバイスであり、Cisco Firewall （FWSM、ASA、または PIX）のバーチャラ

イゼーション機能を利用し、仮想コンテキスト（物理デバイスの代わりに）を、配置された各論理

パーティション専用にするのが一般的な方法です。

• 配置されたファイアウォール デバイスの動作モード：通常、トランスペアレント モード（ファイ

アウォールがレイヤ 2 のブリッジ デバイスのような役割を果たす）またはルーテッド モード

（ファイアウォールがルーテッド ホップになる）の 2 つのオプションがあります。

• このデザインにおいて、ネットワークの仮想化されていない部分（グローバル テーブル）に接続

するにはどうすればよいか：次のように、一般的に導入されるオプションがいくつかあります。

1. グローバル テーブルは、もう 1 つの VPN と考えられ（実際、通常はデフォルトの VPN と考

えられる）、それ自身のセキュリティ デバイスがフロントエンドの役割を果たします。

2. グローバル テーブルは共有サービスとして扱われ、各 VPN からグローバル テーブルへのアク

セスは、サービス エッジが提供するポリシー実施に従います。

以上の 2 つのオプションを図 11 に示します。

RedVPN

GreenVPN

YellowVPN

2262

46

20ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 11 グローバル テーブルの配置オプション

• フュージョン ルータ機能がどのように配置されるか：2 つの も一般的なオプションは、この役割

を果たす個別の物理ネットワーク デバイスを専用にするか、サービス エッジの VPN と同じスイッ

チ内にフュージョン ルータを実装するオプションです。これにより、デュアル ディアおよびシン

グル ティアのサービス エッジ モデルという 2 つの配置シナリオを区別できます。

この後のセクションでは、フュージョン VRF の定義がいかにシングル ティアの配置の要件になり得る

かについて説明します。2 ティアの実装では、フュージョンの機能が外部デバイス上で実行されること

から、フュージョン VRF の定義は必要ない可能性があります。ただし、グローバル テーブルからも共

有サービスにアクセスする必要があるような配置では、フュージョン VRF の使用が必須になります。

すべてのシナリオにこのデザインが一般的に当てはまるように、このマニュアルの残りの部分では、常

にフュージョン VRF を利用した配置について議論します。

この後のセクションでは、上記で説明した変数に基づいて考えられるデザインのバリエーションについ

て、特定のシナリオごとに長所と短所を強調しながら説明します。次の 2 つのモデルについて説明しま

す。

• デュアル ティア

• シングル ティア

それぞれのモデルで、次のデザイン オプションを使用できます。

• トランスペアレント モードでのファイアウォール コンテキスト

ルーティング ピアリング オプション：EIGRP、OSPF、および eBGP

• ルーテッド モードでのファイアウォール コンテキスト

ルーティング ピアリング オプション：eBGP

RedVPN

YellowVPN

RedVPN

GreenVPN

YellowVPN

2262

52

21ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

デュアル ティアの実装

図 12 に、デュアル ティアのサービス エッジ モデルを示します。

図 12 デュアル ティアの実装モデル

D1 および D2 デバイスは、ネットワークのコアに接続されているディストリビューション レイヤ スイッチを表します。上記のように、これらは VRF を定義することで仮想化されています。仮想化され

たネットワークでこれらのデバイスが果たす役割は、その大部分が採用したパス分離方法に依存しま

す。

• MPLS VPN デザインでは、これらのデバイスは PE として配置されます。

• VRF-Lite エンドツーエンド シナリオでは、これらは仮想化されたリンク経由でコアに接続されま

す（サブインターフェイスまたは レイヤ 2 トランクと SVI のいずれかを使用して）。

• VRF-Lite および GRE トンネルを配置する場合は、これらのデバイスは、リモート スパイクが始

点となる GRE トンネルを集約するハブとして機能する可能性が も高くなります。

S1 および S2 は、フュージョン ルータとして機能するデバイスで、さらには（通常は、Firewall Services Module （FWSM）を統合することによって）ファイアウォールの機能も果たします。これら

の機能のために、S1 および S2 は、このマニュアルとの関連では名前付きのサービス スイッチです。

Si

D1 D2

S1 S2

3

3

3

3

Red VPN

Yellow VPN

Green VPN

HSRP

HSRP

HSRP

D1Si L3

L2

L2 L2

L2 L2

Red VPNRed VPN

Red VPN

S2S1

D2

2262

53

22ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 12 の中の論理構成図では、別個のファイアウォール コンテキストが各 VPN のフロント エンド専用

として機能する様子が表されています。異なるコンテキストが（同じ VPN に対して）アクティブ /スタンバイ モードとして機能しますが、トラフィックの負荷分散を向上させるために異なるコンテキス

ト用の S1 および S2 上のアクティブな ファイアウォールを交代させることができます。

デュアル ティアの推奨される配置に関する追加の考慮事項を次にいくつか示します。

• サービス スイッチ内のフュージョン ルータおよびディストリビューション デバイス内に定義され

た VRF は、レイヤ 3 接続とピアリングします。フュージョン ルータに関しては、この目的のため

に特定の VLAN を専用に指定することでこれを達成できます。この VLAN は、サービス スイッ

チに接続しているレイヤ 2 のポートチャネル トランク上で伝送されます。ディストリビューショ

ン VRF に関しては、物理ルーテッド リンクが D1 および D2 に接続します。このリンクは、その

後、各 VRF ペアへのレイヤ 3 接続を提供できるように、仮想化されます（サブインターフェイス

を利用）。

（注） 2 つのファイアウォール モジュール間で復元力の高い接続を提供するために、サービス スイッ

チ間にポートチャネルを使用することを強く推奨します。

• 各ファイアウォール コンテキストの内部インターフェイスは、フュージョン ルータ側になってお

り、外部インターフェイスはディストリビューション レイヤ スイッチ側になっています。この選

択は、共有エリア内に配置されたサービスを保護するための要件によって決まります。

• VLAN の内部および外部両方のファイアウォールがサービス スイッチ間で拡張されますが（ポー

トチャネル レイヤ 2 トランク上で伝送される）、VLAN 内部のファイアウォールには当てはまりま

せん。トランスペアレント モードでのファイアウォールの配置について説明する際に、この選択

の設計上の理由が明らかになります。

• ディストリビューション レイヤ スイッチは、レイヤ 2 トランクを利用して、正方形のトポロジに

よってサービス スイッチに接続されます。VLAN 外部のファイアウォールは、デュアル ディア デバイス間で、これらのトランク接続上を伝送されます。

• 上記の設計を選択した結果、ディストリビューション スイッチとサービス スイッチ間にループフ

リーのトポロジが作成されます。スパニング ツリーをアクティブにすることを常にお勧めします

が（設定またはケーブル接続エラーによるループを防ぐため）、リンクのブロックには設計上関与

しません。これは、全体的なサービス エッジ デザインの復元力に役立ちます。

このタイプの配置は、データセンターの配置で通常推奨されるものとはわずかに異なる点に注意してく

ださい。データセンターの設計指針の詳細については、次を参照してください。

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/dc_servchas/service-chassis_design.html

この後のセクションでは、トランスペアレント モードまたはルーテッド モードで機能しているファイ

アウォール コンテキストを利用した、デュアル ティア モデル用の 2 つの異なる配置について説明しま

す。表示されている設定例およびコンバージェンス結果は、次の特徴を持つテストベッドで得られたも

のです。

• サービス スイッチおよびディストリビューション スイッチとして Sup720 3BXL を搭載した Catalyst 6500 が配置されました。テストされた IOS リリースは 12.2(33)SXH4 でした。eBGP をディストリビューション VRF とフュージョン ルータ間のルーティング ピアリング プロトコルと

して利用する場合、いくつかの修正が行われているので（CSCsl39233 および CSCsu03167）、サービス エッジの配置にこのリリースを使用することを強くお勧めします。

• Firewall Services Module （FWSM） が、3.2(8) リリースで動作するマルチコンテキスト モードで

配置されています。ファイアウォールのフェールオーバー シナリオに役立つ重要な修正 （CSCsr11309）を利用できるようにするために、この 小限のリリースの使用が必要になります。

23ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

（注） Cisco ASA を同じ目的で使用するためのマニュアルは、このマニュアルの将来的なリリースで予定さ

れています。

トランスペアレント モードで配置されたファイアウォール コンテキスト

トランスペアレント モードでファイアウォール コンテキストを配置するのは、非常に一般的なアプ

ローチです。これは、すでに使用中の IP アドレスを変更する必要なしにネットワークにファイア

ウォールを挿入できるためです。これは主に、ファイアウォールがレイヤ 2 のデバイスのように働き、

インターフェイスの内部と外部の間でトラフィックをブリッジするためです。

（注） このマニュアルが作成された時点では、トランスペアレント モードでファイアウォール コンテキスト

を配置する場合に定義できたのは 2 つのインターフェイスだけでした。

トランスペアレント モードを使用するもう 1 つの利点として、図 13 で示すように、 下部に定義され

た VRF と 上部に定義されたフュージョン ルータ間でルーティング ピアリングを確立できることが挙

げられます。

図 13 トランスペアレント モードでのファイアウォール コンテキストとのルーティング ピアリング

この機能で使用されるルーティング プロトコルの種類は、通常は、採用されたパス分離方法によって

決まります。

• MPLS VPN 構成では、キャンパス インフラストラクチャ全域で VPN ルートを交換している PE デバイス間に iBGP がすでに存在するために、eBGP を使用するように推奨されます。

• VRF-Lite エンドツーエンド（または VRF-Lite + GRE）の構成では、通常は、各仮想ネットワー

ク内部でコントロール プレーン プロトコルとしてすでに使用されている同じ IGP がこの種類のピ

アリングにも利用されます。

VPN

L2L2 L2

OSPF EiGRPeBGP

2262

54

24ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

トランスペアレント モードで配置されたファイアウォールを使用するサービス エッジ用に推奨される

配置モデルを図 14 に示します。この例では、2 つの VPN （Red および Green）の配置を示していま

す。図 14 で示している特定の VPN/IP サブネット情報は、このセクションの残りの部分で示されてい

る設定例に使用されています。

図 14 トランスペアレント モードのファイアウォール コンテキストの例

図 14 で示すように、Red および Green の VPN は、トランスペアレント モードで配置されている 2 つのファイアウォール コンテキストがフロントエンドになっており、インターフェイスの外部と内部の

ファイアウォール上に配置された VLAN からのトラフィックをブリッジしています。また、S1 内部の

ファイアウォール コンテキストはアクティブで、S2 内のファイアウォール用のコンテキストはスタン

バイ モードになっています。Red ファイアウォール コンテキストが S1 でアクティブであり、Green ファイアウォール コンテキストが S2 でアクティブであるような、アクティブ -アクティブ モデルを配

置することもできます。

推奨される配置モデルに関する追加の考慮事項を次にいくつか示します。

• HSRP は、この場合に 適な First Hop Redundancy Protocol で、次のインターフェイス用に仮想

ゲートウェイ機能を提供するのに利用されます。

D1 D2

.3

.3

.2

.2

10.136.0.42/30

.33 .34

.43 .44

S1 S2VLAN 903 10.136.103.0/24 VLAN 904 10.136.104.0/24

VLAN 1054 10.136.104.0/24VLAN 1053 10.136.103.0/24

HSRP VIP .4VLAN 903 904

HSRP VIP .1VLAN 1053 1054

.6 .5.6 .5

VLAN 32 10.136.32.0/24

HSRP VIP .1

10.136.200.0/30.1 .2

Red VPN

Green VPN

10.136.0.32/30

2262

55

25ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

– 共有サービス サブネット（VLAN 32）：これは、フュージョン デバイスに直接接続されてい

るサブネット内に共有サービスが配置されていることが前提です。

– サブネット内のファイアウォール（Red VPN には VLAN 903、Green VPN には VLAN 904）。

– サブネット外のファイアウォール（Red VPN には VLAN 1053、Green VPN には VLAN 1054）。

• ディストリビューション レイヤ スイッチ内に配置されたフュージョン ルータおよび VRF は、

ルーテッド リンクにも接続されています。これは、特定の障害状態において、トラフィックの再

ルーティングを行うのに使用されるレイヤ 3 パスを提供するためのものです（後ほど説明します）。

• フュージョン ルータは、キャンパス VPN ごとに専用で使用される個別のインターフェイス（ここ

では VLAN インターフェイス）を定義します。上記の例では、SVI 903 を利用して Red VPN との

通信が確立され（Red ファイアウォール コンテキスト経由）、SVI 904 を使用して Green VPN への

接続が確立されます。

ファイアウォールをトランスペアレント モードで配置する場合、BPDU のフローを許可するために、

特定の ACL を各ファイアウォール コンテキスト上に定義するのが一般的なベストプラクティスです。

これは、（前述のような）冗長シナリオにおいて、両方のファイアウォール コンテキストが（たとえ

ば、キープアライブ メッセージの消失が原因で）アクティブな状態になる際に作成される可能性があ

るスパニング ツリー ループを検出できるようにするために重要です。特定の ACL （通常は名前付き

の EtherType ACL） を次に示します。

access-list BPDU ethertype permit bpdu

EtherType トラフィックはコネクションレス型なので、内部および外部インターフェイスの両方にこの ACL を適用する必要があります。

access-group BPDU in interface outside-vrf-redaccess-group BPDU in interface inside-vrf-red

（注） 全体的なファイアウォール コンテキスト設定の説明は、このマニュアルの範囲外です。具体的な情報

については、次のデータセンターのデザイン ガイドを参照してください。http://www.cisco.com/en/US/netsol/ns743/networking_solutions_program_home.html

上記の設定では、HSRP パケットもファイアウォールを通過できるという興味深い結果が得られます。

このことは、ファイアウォールの内側および外側にある VLAN に関連付けられた共通サブセットが原

因で、使用するシナリオに問題を引き起こす可能性があります。HSRP が適切に機能し、望ましい動作

を示すようにするには、次に示すように、サービスおよびディストリビューション レイヤ デバイス用

に別の HSRP グループを設定する必要があります。

サービス スイッチ（S1 および S2）interface Vlan903 interface Vlan903 description Firewall Inside Red VRF description Firewall Inside Red VRF ip vrf forwarding fusion ip vrf forwarding fusion ip address 10.136.103.6 255.255.255.0 ip address 10.136.103.5 255.255.255.0 standby 1 ip 10.136.103.4 standby 1 ip 10.136.103.4 standby 1 timers msec 250 msec 750 standby 1 timers msec 250 msec 750 standby 1 priority 105 standby 1 preempt delay minimum 180

ディストリビューション スイッチ（D1 および D2）interface Vlan1053interface Vlan1053 description Firewall Outside Red VRF description Firewall Outside Red VRF ip vrf forwarding Red ip vrf forwarding Red ip address 10.136.103.3 255.255.255.0 ip address 10.136.103.2 255.255.255.0 standby 2 ip 10.136.103.1 standby 2 ip 10.136.103.1

26ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

standby 2 timers msec 250 msec 750 standby 2 timers msec 250 msec 750 standby 2 priority 105 standby 2 preempt delay minimum 180

この設定によって、S1 がサブネット内のファイアウォール上のアクティブな HSRP デバイスになり、

D1 がサブネット外のファイアウォール上のアクティブな HSRP の役割を果たすようになります。

適なルーティング プロトコルが通過できるように各ファイアウォール コンテキスト上のフィルタが

適切に配置されている場合には（EIGRP、OSPF、および eBGP に必要な設定は、このマニュアルのプ

ロトコル特有のセクションで後ほど説明されます）、図 15 で示すように、ディストリビューション スイッチ内で定義された VRF が両方のフュージョン ルータとピアリングします。

図 15 フルメッシュのルーティング ピアリング

特定のルーティング ドメイン内で宛先が不明である場合は、各 VPN が常にトラフィックをサービス エッジに向けるようにしたいので、通常の配置では、フュージョン ルータは、D1 および D2 内で定義

されている各 VRF にデフォルト ルートを通知するだけになります。同時に、各 VRF は、リモート キャンパスのサブネットをフュージョン ルータに通知します。結果的に、コアと共有サービス エリア

間のトラフィックは、図 16 で説明されるパスをデフォルトで流れることになります。

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPN

S2S1

2262

56

27ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 16 コアからサービスへのトラフィック フロー

このように動作する理由は、デフォルトでは、各フュージョン ルータが両方の VRF に対する等コスト

のデフォルト ルートを通知するためです。すべてのトラフィック フローは、ネクストホップが S1 また

は S2 内のフュージョン ルータであるという事実とは関係なしに、S1 内のアクティブなファイア

ウォールを通過するように要求されます。

（注） さらに、（一般的なデフォルト ルートの代わりに）特定の共有サービス サブネットがフュージョン ルータからディストリビューション レイヤ スイッチ内で定義された VRF に通知される場合、同じトラ

フィック フローが見られます。

図 16 で示すフローは、準 適なもので、サービス スイッチ間のトランジット リンクを利用し過ぎてい

ます。このシナリオを 適化するために推奨されるソリューションは、S1 内のフュージョン ルータが

デフォルト ルート用の優先されるメトリックをディストリビューション VRF に通知するようにルー

ティングを調整することです。この調整に関する詳細については、この後のルーティング プロトコル

固有のセクションで説明します。トラフィック フローに関する 終結果は図 17 で示されています。

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPNRed VPN

S2S1 S2S1

2262

57

28ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 17 コアからサービスへのトラフィック フローの最適化

図 18 では、別方向のフロー（共有サービスからキャンパス コアへのフロー）が示されています。

図 18 共有サービスからコアへのトラフィック フロー

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPNRed VPN

S2S1 S2S1

2262

58

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPNRed VPN

S2S1 S2S1

HSRP HSRP 22

6259

29ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

すべてのリターン トラフィック フローは、まず S1 に送信されます。これは、S1 が共有サービス サブ

ネット（VLAN 32）上のアクティブな HSRP デバイスであるためです。これは、フュージョン ルータ

に直接接続されているサブネット上に共有サービスが配置されている場合です。この時点で、フローの 50% が D1 に送信され（光ファイバによる直接リンク経由）、残りの 50% がサービス スイッチ間のト

ランジット リンクを利用して D2 に送信されます。これは、ディストリビューション レイヤ スイッチ

内で定義された Red VRF がリモート キャンパスの宛先への等コストのパスを提供するためです。トラ

フィック フローが、図 17 で示すフローといかに対称的であるかに注意してください。

この後のセクションでは、異なる障害シナリオにおける復旧動作について説明します。障害が発生する

たびに起こるトラフィック フローに関する考慮事項は、VRF とフュージョン ルータ間に導入された

ルーティング プロトコルとは関係ありません。この後のセクションでは、各ルーティング プロトコル

に関して、具体的な復旧方法と復旧時間について説明します。

（注） マニュアルのこの部分における冗長性に関する話題は、シングル サイトの配置での復旧方法に焦点が

当てられます。冗長サイトの考慮事項に関しては、「仮想ネットワークにおけるサイト冗長性の計画」 を参照してください。

コンバージェンス分析

ディストリビューション スイッチとサービス スイッチ間の光ファイバ障害

D1 と S1 間の光ファイバによる接続に障害が発生すると、D1 には、新しくアクティブになったファイ

アウォール モジュールに対してアクティブなレイヤ 2 パスが存在しないので、D1 内の VRF とフュー

ジョン ルータ間のピアリングが削除されます。トラフィック フローに影響する結果を、図 19 に示しま

す。

図 19 D1 と S1 間の光ファイバ障害後のトラフィック フロー

S2

S1 S2S1

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPNRed VPN

HSRP

2262

60

30ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

• コアからサービスへのフロー：D1 は、フュージョン ルータからデフォルト ルート（または、共有

サービス サブネット用のより具体的なルート）を受信するのを停止し、同様の情報をディストリ

ビューション スイッチに接続しているルーテッド リンク経由で D2 から受信し始めます。その結

果、その情報を D2 よりも劣るメトリックで D1 がキャンパス コアに通知し始めるので、コアから

共有サービス エリアに向けられたすべてのトラフィックが D2 に配信されるようになります。この

場合に発生するコンバージェンスは、D1 が光ファイバの障害を検知する速さに基づきます。リン

ク障害検出が機能する場合、これは非常に高速で、サブセカンドの中断時間しか生じません。

• サービスからコアへのフロー：S1 内のフュージョン ルータは、光ファイバの障害とは関係なく HSRP としてのアクティブな役割を維持します。ただし、フュージョン ルータと D1 内の VRF 間のルーティング ピアリングがダウンするまで、フュージョン ルータは、その VRF 内のリモート キャンパス ロケーション宛てのフローの 50% を D1 に送信しようとするので、これらのトラ

フィック フローに対してブラックホールが発生してしまいます。ピアリングが削除されると、S1 内のフュージョン ルータが D2 内の VRF だけをリモート キャンパス宛先に対する次のホップとし

て使用し始めます。これは、これらのフローがサービス スイッチ間のトランジット リンク経由で D2 に到達する必要があることを意味します。コンバージェンスの観点からすると、ここで中断時

間の長さを決定する主な要因は、S1 内のフュージョン ルータが D1 内の VRF とのルーティング ピアリングを除去するのに要する時間です。これは、通常は設定されたルーティング プロトコル

の保持時間に直接関係します。

サービス スイッチと共有サービス エリア間の光ファイバ障害

サービス スイッチ S1 を共有サービス エリアに接続している光ファイバ リンクに障害が発生しても、

VRF とフュージョン ルータ間のルーティング ピアリングには変化はありません。トラフィック フロー

は、図 20 で示すようになります。

図 20 S1 と共有サービス エリア間の光ファイバ障害後のトラフィック フロー

• コアからサービスへのフロー：S1 内のフュージョン ルータがディストリビューション レイヤ内の VRF に通知するデフォルト ルートを学習する方法に応じて、トラフィック フローには次の 2 つの

異なるシナリオが考えられます。

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPN

S2S1 S2S1

Red VPN

HSRP 22

6261

31ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

– スタティック ルートがネクストホップ デバイスから学習されるのではなく、ローカルで生成

される場合（これは、後ほど説明するように、導入されたルーティング プロトコルに応じて

異なる方法で実現されます）、S1 内のフュージョン ルータは光ファイバの障害後もデフォルト ルートの通知を続行します。これは、共有サービスに配信されるには、図 14

（10.136.200.0/24 サブネット）で示すようにルーテッド リンク越しにトラフィックを再ルー

ティングする必要があることを意味します。

– スタティック ルートが通常は共有サービス エリア内のネクストホップ デバイスから学習され

る場合は、S1 はこの情報を学習、および VRF に対するこの情報の通知を停止します。ただ

し、S1 内部にアクティブなファイアウォールが残るので、トラフィック フローは、前の箇条

書き項目内のシナリオとまったく同じに見えます。

• サービスからコアへのフロー：S2 内のフュージョン ルータが 共有サブネット上でアクティブな HSRP デバイスになり（HSRP メッセージは、サービス エリア内のスイッチへの接続経由で交換さ

れる）、アクティブなファイアウォールがそのデバイス内にあるので、すべてのトラフィック フローをトランジット リンク越しに S1 に送信する必要があります。トラフィック フローは、逆方向

でも同一のように見えます。コンバージェンスの観点からすると、中断時間は、S2 内のフュー

ジョン ルータが共有サービス サブネット（VLAN 32）上でアクティブな HSRP デバイスになるの

に必要な時間によって決まります。この値を 小化するには、次に示すようにサブセカンド HRSP タイマーを設定することをお勧めします。

S1interface Vlan32 description Shared Services ip vrf forwarding fusion ip address 10.136.32.3 255.255.255.0 standby 1 ip 10.136.32.1 standby 1 timers msec 250 msec 750 standby 1 priority 105 standby 1 preempt delay minimum 180

S2interface Vlan32 description Shared Services ip vrf forwarding fusion ip address 10.136.32.2 255.255.255.0 ip flow ingress standby 1 ip 10.136.32.1 standby 1 timers msec 250 msec 750

150 以下の VLAN の配置では、サブセカンド HRSP タイマーの使用をお勧めします。詳細につい

ては、次のキャンパス デザイン ガイドを参照してください。http://www.cisco.com/en/US/netsol/ns815/networking_solutions_program_home.html

（注） 図 20 で示したトランジット リンク越しの準 適なパスを避けるために、可能であれば各サービス スイッチおよび共有サービス エリア間にポートチャネルを配置することをお勧めします。

アクティブなファイアウォール モジュールの障害

S1 内でファイアウォール モジュールに障害が発生すると、VRF およびフュージョン ルータは、S2 内部で新しくアクティブになったファイアウォールによってルーティング ピアリングを保持します。結

果的に生じるトラフィック フローを図 21 に示します。

32ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 21 ファイアウォールの障害後のトラフィック フロー

• コアからサービスへのフロー：D1 および D2 は、S1 内のフュージョン ルータ経由でベスト ルート

を学習し続けます。その結果、トラフィック フローの 50% が図 21 に示す準 適なパスを経由し、

サービス スイッチ間のトランジット リンクを 2 回通過します。これらのフローが確立されるまで

の全体の中断時間は、主に S2 内のファイアウォールがアクティブになるまでの時間に左右されま

す。これは、この時間よりも設定されたルーティング プロトコルの保持時間が長いことが前提で

す。そうでない場合は、ファイアウォールのフェールオーバー時間に加えて、ルーティング プロ

トコルのピアリングを再確立し、ルーティング情報を通知するのに必要な時間を考慮する必要があ

ります（さらに具体的な考慮事項については、この後のプロトコル固有のセクションを参照してく

ださい）。S2 内のファイアウォール モジュールが他方のファイアウォールの障害を検知し、アク

ティブ デバイスになるのに必要な時間は、ファイアウォール間で設定された保持時間に依存する

ことに注意してください。FWSM では、次に示すように、保持時間を 3 秒未満には設定できませ

ん。

FWSM(config)# failover polltime unit msec 500 holdtime ?configure mode commands/options: <3-45> Hold time in seconds, default is 3 X poll time but minimum is 3 Seconds

• サービスからコアへのフロー：ファイアウォールの障害とは関係なく、S1 はアクティブな HSRP デバイスのままになるので、共有サービス エリアからのすべてのトラフィックは、このデバイス

に配信されます。S1 は、ディストリビューション レイヤ内の両方の VRF 経由でリモート キャン

パスの宛先を学習し続けるので、トラフィックの 50% は、前述の準 適なパスと同じパスを通過

します。この方向にかかる復旧時間には、前の箇条書き項目で説明したのと同じ考慮事項が当ては

まり、コンバージェンスは、ファイアウォールがフェールオーバーできる速度や、その間にデバイ

ス間のピアリングが切断したか否かに依存します。

推奨設計：S2 内部でファイアウォール モジュールがアクティブな場合に、図 21 で示した準 適なパ

スが使用されるので、S1 内部のファイアウォールが（動作中に）常にアクティブの役割を果たすよう

にファイアウォールの先取りを設定するようにお勧めします。

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPN

S2S1 S2S1

Red VPN

HSRP

2262

62

33ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

サービス スイッチの障害

この障害シナリオを図 22 に示します。

図 22 サービス スイッチの障害後のトラフィック フロー

サービス スイッチ S1 全体の障害のため、S1 内の VRF とフュージョン ルータ間のピアリングが削除さ

れます。また、D1 は、新しくアクティブになったファイアウォール モジュールへのアクティブなレイ

ヤ 2 パスを持たないので、D2 内の VRF だけが S2 内のフュージョン ルータとのルーティング ピアリ

ングを確立できます。結果的に、トラフィック フローは次のようになります。

• コアからサービスへのフロー：D2 と S2 間のリンクは、コアから共有サービスへの唯一利用可能

なパスです。コンバージェンスの観点からすると、中断時間はファイアウォールがアクティブにな

るまでの時間によって決まり、ルーティング ピアリングを連続的に確立できます。この中断時間

の実体は、ファイアウォールの障害のシナリオで説明したものと同じであると考えることが可能で

す。

• サービスからコアへのフロー：フュージョン ルータは、D2 内の VRF 経由の、リモート キャンパ

スの宛先への有効なパスだけを持っています。S1 スイッチの障害のために、S2 がアクティブな HSRP デバイスになります。復旧のメカニズムは、前の箇条書き項目内で説明したものと同じで

す。

ディストリビューション スイッチの障害

後の関連シナリオは、図 23 に示すように、ディストリビューション スイッチの障害です。

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPNRed VPN

S2S1 S2S1

HSRP

2262

63

34ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 23 ディストリビューション スイッチの障害後のトラフィック フロー

トラフィック フローおよびルーティング ピアリングの観点からは、このシナリオは D1 と S1 間の光

ファイバ障害に関連するシナリオと非常に似ています。

• コアからサービスへのフロー：D1 スイッチ全体に障害が発生しているので、コア デバイスはそれ

を通過する有効なパスを削除し、すべてのトラフィックを D2 経由で再ルーティングします。前と

同様、リンク障害検出が機能する場合、これはサブセカンドの中断時間しか生じない ECMP の再

ルーティングです。

• サービスからコアへのフロー：フュージョン ルータには、ディストリビューション スイッチに障

害が発生したことを検知する方法がありません（それらの間にファイアウォールがあるからです）。

その結果、このルータは、ルーティング ピアリングが削除されるまで D1 内の VRF にトラフィッ

クを送信し続けます。これが、この場合にコンバージェンスを決定する主なメカニズムになりま

す。

この後のセクションでは、異なるルーティング プロトコルの導入について、具体的な設計と設定に関

する考慮事項について説明します。それぞれのケースには、前に説明したすべての障害のシナリオのコ

ンバージェンスの結果が含まれます。

VRF およびフュージョン ルータ間での EIGRP の使用

ディストリビューション スイッチ（D1 および D2）上に定義された VRF とフュージョン ルータ間の

ピアリングに利用できる 初のオプションは、EIGRP を利用するオプションです。これは特に、定義

された各仮想ネットワークとの関連で EIGRP を利用する VRF-Lite エンドツーエンドの配置に対して

推奨されます。

必要な設定手順は次のとおりです。

1. ファイアウォール コンテキストを越えた EIGRP の隣接関係の確立の許可：ディストリビューショ

ン レイヤの各 VRF に対して EIGRP がすでに有効になっており、それをサービス スイッチ上で有

効化する必要があることが前提です。これは通常、VRF-Lite エンドツーエンドを利用して VPN ごとにキャンパス間の接続性を提供する場合です。

S2

S1 S2S1

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPNRed VPN

HSRP

2262

64

35ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

必要な設定は次のとおりです（S1 と S2 の両方に有効）。

router eigrp 100!address-family ipv4 vrf fusion network 10.0.0.0 no auto-summary autonomous-system 100 exit-address-family

（注） VRF-Lite 環境における EIGRP の配置に関する詳細については、http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/PathIsol.html を参照してください。

異なる障害のシナリオにおけるトラフィック復旧は、設定された保持時間に左右されるので、

EIGRP タイマーを調整して Hello タイマーと保持時間タイマーを 小値に低減することをお勧め

します。これは、サービス スイッチ上の SVIs 903 およびディストリビューション スイッチ上の SVIs 1053 に適用する必要のある、次に示す設定を使用して実行する必要があります。

interface Vlan1053 ip vrf forwarding Red ip address 10.136.103.3 255.255.255.0 ip hello-interval eigrp 100 1 ip hold-time eigrp 100 3

次の特定の EtherType が、いったんインターフェイスの内部および外部に適用されると、EIGRP プロトコルは、トランスペアレント モードで実行されているファイアウォールを自動的に通過で

きるようになることに注意してください。

access-list BPDU ethertype permit bpdu

その結果、次で示すように、EIGRP の隣接関係が S1 内のフュージョン ルータとディストリ

ビューション レイヤ スイッチ内の VRF 間に確立されます。

D1D1#sh ip eigrp vrf Red neighbors IP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num2 10.136.103.2 Vl1053 2 00:04:06 4 200 0 417514901 10.136.103.5 Vl1053 2 00:04:06 6 200 0 500 10.136.103.6 Vl1053 2 00:04:06 3 200 0 1145 10.136.0.33 Te1/3.532 13 15:44:26 1 200 0 417514894 10.122.35.34 Te1/1.632 7 15:45:08 1 200 0 49261383 10.122.35.38 Te1/2.732 2 15:45:09 1 200 0 51781844

D2D2#sh ip eigrp vrf Red neighbors IP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num1 10.136.103.3 Vl1053 2 00:05:39 10 200 0 12545 10.136.0.32 Te1/3.532 12 15:45:59 1 200 0 12554 10.122.35.36 Te1/1.732 7 15:46:02 1 200 0 49261373 10.122.35.40 Te1/2.632 2 15:46:03 1 200 0 517818422 10.136.103.6 Vl1053 2 15:46:04 1 200 0 1140 10.136.103.5 Vl1053 2 15:46:04 1 200 0 50

36ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

Red VRF はお互いにピアリングし、さらに S1 と S2 内のフュージョン ルータと SVI 1053 経由で

ピアリングします。また、それらはお互いにピアリングし、Ten1/1、Ten1/2、および Ten1/3 のサ

ブインスタンスを定義する、配置されたルーテッド リンク経由でコアに配置されたデバイスとも

ピアリングします。

S1S1#sh ip eigrp vrf fusion neighbors IP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num3 10.136.200.2 Vl200 13 00:00:34 1 200 0 610 10.136.103.3 Vl903 2 00:13:51 4 200 0 12541 10.136.103.2 Vl903 2 15:54:16 1 200 0 417514902 10.136.103.5 Vl903 2 15:58:18 1 200 0 62

S2S2#sh ip eigrp vrf fusion neighbors IP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num3 10.136.200.1 Vl200 11 00:01:16 1 200 0 1240 10.136.103.3 Vl903 2 00:14:34 4 200 0 12582 10.136.103.2 Vl903 2 15:54:58 1 200 0 417514931 10.136.103.6 Vl903 2 15:59:00 1 200 0 122

フュージョン ルータは、ディストリビューション レイヤ デバイスの D1 と D2 上に定義された VRF とピアリングし、VLAN 903 上でお互いにピアリングします。サービス スイッチ間でレイヤ 3 のピアリングを確立するために、別の SVI 200 も定義されます。このピアリングは、特定の障害

シナリオにおいて、共有サービスからキャンパス コアに向けてトラフィックを再ルーティングす

る場合に使用される可能性があります。

2. 各 VPN にデフォルト ルートを通知するようにフュージョン ルータを設定：すでに述べたように、

定義された各 VPN が、特定の VPN に関連して宛先が不明である場合は常に、トラフィックをこ

の中央のロケーションに向けるようにするのが目的です。ここでは、デフォルト ルートがフュー

ジョン ルータのルーティング テーブルに存在することが前提です。これは、フュージョン ルータ

がその情報をネクストホップ ルータから学習するか（これは、たとえばインターネット エッジを

配置する場合）、静的に定義されているためです。トラフィック フローを 適化するためには、S1 内のフュージョン ルータが設計上デフォルト ルート用により良いメトリックを通知するように、

ルーティング プロトコルを調整することが必要です。望ましい動作になるような設定を次に示し

ます（S1 と S2 両方のデバイス用）。

S1router eigrp 100 ! address-family ipv4 vrf fusion redistribute static network 10.0.0.0 default-metric 100000 100 255 1 1500 distribute-list Default out Vlan903 no auto-summary autonomous-system 100 eigrp router-id 10.136.200.1 exit-address-family!ip access-list standard Default permit 0.0.0.0

S2router eigrp 100

37ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

offset-list Default out 1000 Vlan903 ! address-family ipv4 vrf fusion redistribute static network 10.0.0.0 default-metric 100000 100 255 1 1500 distribute-list Default out Vlan903 no auto-summary autonomous-system 100 eigrp router-id 10.136.200.2 exit-address-family!ip access-list standard Default permit 0.0.0.0

上の例に有効ないくつかの考慮事項：

• redistribute static コマンドは、デフォルト ルートをルーティング テーブルに挿入するのに使用さ

れます。これは、S1 と S2 がネクストホップ デバイスからデフォルトを学習するようなシナリオ

では必要ありません。

• SVI 903 から通知されるルートのメトリックを増やすことで、ディストリビューション VRF が S1 内のフュージョン ルータによって通知されたルートを常に優先するように、S2 上で offset-list が設定されます。offset-list コマンドが、フュージョン VRF にマッピングされたインターフェイス

に適用されるにもかかわらず、グローバル EIGRP 設定スペースの下でどのようにリストされてい

るかに注意してください。

• distribute-list は、S1 と S2 がディストリビューション スイッチ内の VRF に通知するルートをフィ

ルタリングするのに適用されます。この特定の例では、デフォルト ルートだけが許可されます。

distribute-list の使用を強くお勧めします。これを使用しないと、フュージョン ルータが Red VRF に他の VPN のルーティング情報も通知してしまいます（フュージョン ルータでは、すべてのキャ

ンパス プレフィクスの完全な VPN 間のビューが可能なことを覚えておいてください）。これによ

り、デフォルトで VPN 間通信が確立されなくても（確立するには、特定のポリシーを各ファイア

ウォール コンテキスト上で設定する必要があります）、前述の動作は望まれるものではありませ

ん。

結果的には、以下に示すように、D1 と D2 の両方が S1 からデフォルト ルートを学習します。

D1D1#show ip route vrf Red supernets-only Routing Table: RedCodes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static routeGateway of last resort is 10.136.103.6 to network 0.0.0.0D*EX 0.0.0.0/0 [170/51456] via 10.136.103.6, 1d00h, Vlan1053

D2D2#show ip route vrf Red supernets-only Routing Table: RedCodes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route

38ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

Gateway of last resort is 10.136.103.6 to network 0.0.0.0D*EX 0.0.0.0/0 [170/51456] via 10.136.103.6, 5d22h, Vlan1053

結果的に、コアから共有サービス エリアへのトラフィック フローは、図 17 で示したようになります。

EIGRP コンバージェンスの結果

前に説明した別の障害シナリオでのコンバージェンスの結果を次にまとめます。

テスト 1 （S1 と D1 間の光ファイバの障害）

• コアからサービスへのフロー：<1 秒

この値は、S1 へ接続する光ファイバ リンクの障害が D1 デバイスによって検知される速度によっ

て決まります。これにより、SVI 1053 が DOWN 状態になり、その結果、ルーティング テーブル

からそのインターフェイス経由で学習したデフォルトのルートが削除されます。このイベントは、

通常はリンク障害検知のメカニズムによって開始され、そのために非常に高速です（サブセカンド

のコンバージェンス）。

• サービスからコアへのフロー： ～ 3 秒

この値は、フュージョン ルータが D1 から学習したルートをルーティング テーブルから削除でき

る速度によって決まります。前述したように、SVI は D1 上で DOWN 状態なので、ルートが削除

されるまでトラフィックはブラックホールに入ってしまいます。この検知の主な要因は、設定され

た EIGRP の保持時間です。この値によって、検知までの時間を 3 秒にアグレッシブに調整するよ

うな推奨が正当化されます。この動作は、S1 内のフュージョン ルータ上で取得された次の出力の

ようになります。

Dec 9 16:13:10.414 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/23, changed state to downDec 9 16:13:10.426 EST: %LINK-3-UPDOWN: Interface GigabitEthernet2/23, changed state to downDec 9 16:13:10.418 EST: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet2/23, changed state to downDec 9 16:13:10.422 EST: %LINK-SP-3-UPDOWN: Interface GigabitEthernet2/23, changed state to downDec 9 16:13:12.894 EST: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.136.103.3 (Vlan903) is down: holding time expiredDec 9 16:13:12.894 EST: RT(fusion): delete route to 10.137.32.0 via 10.136.103.3, eigrp metric [90/3840]

前述のように、S1 内のフュージョン ルータと D1 内の VRF 間の EIGRP のピアリングが削除され

ると、EIGRP の保持時間の期限が切れるため、リモート宛先（10.137.32.0）へのルートが削除さ

れます。

テスト 2 （S1 と共有サービス エリア間の光ファイバの障害）

• コアからサービスへのフロー：<1 秒

S1 内のフュージョン ルータ宛てのすべてのトラフィック フローを、トランジット リンク越しに S2 へ再ルーティングする必要があります。再ルーティングによって、通常、サブセカンドの中断

時間が生じます。

• サービスからコアへのフロー：<1 秒

共有サービス エリアからのトラフィックは、S2 内のフュージョン ルータが共有サービスのサブ

ネット（VLAN 32）上でアクティブな HSRP デバイスになるまで、ブラックホールに入ってしま

います。サブセカンドの HSRP タイマーを設定すると、このコンバージェンス イベントがサブセ

カンド以内に収まります。

テスト 3 （ファイアウォールの障害）

39ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

• コアからサービスへのフロー： ～ 4、5 秒

• サービスからコアへのフロー： ～ 4、5 秒

前述のトラフィックの中断時間の一因となる 2 つの主要なコンポーネント：

– S2 内のファイアウォールがアクティブな役割を担うまでに必要な時間：これは現在、FWSM の配置では 3 秒未満に設定できません。

– EIGRP タイマーがアグレッシブに設定される場合、隣接関係がリセットされる可能性があり

ます（新しいファイアウォールがトラフィックを送信し始めるのに必要な 3 秒が与えられた場

合）。EIGRP のピアリングを再確立するのに必要な時間を考慮する必要があるので、全体の中

断時間は 4 ～ 5 秒になります。EIGRP の隣接関係がリセットされないようにするには、

EIGRP タイマーのアグレッシブ設定を低めにできます。これにより、EIGRP の保持時間が、

トラフィックの全体的な中断時間を決める主な要因になるような場合、障害シナリオ（たとえ

ば、光ファイバの障害のシナリオ）の復旧時間に影響が及んでしまうことに注意してくださ

い。

テスト 4 （サービス スイッチの障害）

• コアからサービスへのフロー： ～ 4、5 秒

• サービスからコアへのフロー： ～ 4、5 秒

ファイアウォールの障害のシナリオにおける考慮事項がここでも当てはまります。

テスト 5 （ディストリビューション スイッチの障害）

• コアからサービスへのフロー：<1 秒

この場合の復旧メカニズムは、ディストリビューション スイッチに障害が発生した場合の、コア デバイスからの ECMP になります。障害が発生するスイッチに直接接続されているコア デバイス

上でリンク検知メカニズムが適切に機能している場合、これは非常に高速に行われます。

• サービスからコアへのフロー： ～ 3 秒

S1 上のフュージョン ルータ（アクティブな HSRP デバイス）が、上記のテスト 1 のシナリオと同

様、EIGRP ピアリングが削除されるまで障害の発生したスイッチ内部の VRF にトラフィックを送

信し続けるため、復旧時間は設定された EIGRP 保持時間に依存します。

VRF とフュージョン ルータ間での OSPF の使用

定義された各仮想ネットワークとの関連で OSPF を利用する VRF-Lite エンドツーエンドの配置には、

ディストリビューション スイッチ（D1 および D2）とフュージョン ルータ間のピアリングに OSPF を使用することを特にお勧めします。

必要な設定手順を次に示します。

1. ファイアウォール コンテキストを越えた OSPF の隣接関係の確立の許可：ディストリビューショ

ン レイヤの各 VRF との関連で OSPF がすでに有効になっており、それをサービス スイッチ上で有

効化する必要があることが前提です。必要な設定は次のとおりです（S1 と S2 の両方に有効、

router-id の値は例外）。

router ospf 100 vrf fusion router-id 10.136.100.1 log-adjacency-changes auto-cost reference-bandwidth 10000 capability vrf-lite timers throttle spf 10 100 5000 timers throttle lsa all 10 100 5000 timers lsa arrival 80 passive-interface default no passive-interface Vlan200 no passive-interface Vlan903

40ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

network 10.136.0.0 0.0.255.255 area 136

（注） VRF-Lite 環境における OSPF の配置に関する詳細については、http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/PathIsol.html を参照してください。

異なる障害のシナリオにおけるトラフィック復旧は、設定された保持時間に左右されるので、

OSPF タイマーを調整して Hello タイマーと保持時間タイマーの値を低減することをお勧めしま

す。これは、サービス スイッチ上の SVIs 903 およびディストリビューション スイッチ上の SVIs 1053 に適用する必要のある、次に示す設定を使用して実行する必要があります。

interface Vlan1053 ip vrf forwarding Red ip address 10.136.103.3 255.255.255.0 ip ospf hello-interval 1

また、次に示すように、hello の間隔の設定はデッド タイマーの値を暗黙のうちに 4 倍大きな値に

設定します。

D1#sh ip ospf 4 interface vlan1054Vlan1054 is up, line protocol is up <snip> Timer intervals configured, Hello 1, Dead 4, Wait 4, Retransmit 5

（注） サブセカンドの OSPF タイマーの設定は推奨されません。

EIGRP プロトコルとは異なり、OSPF パケットは、EtherType ACL ではトランスペアレント モー

ドで実行中のファイアウォールを通過できないことに注意してください。次に示すように、OSPF がファイアウォールを通過できるようにするには、特定の ACE が必要です。

access-list <ACL_NAME> extended permit ospf any any

前の設定手順の結果、次で示すように、OSPF の隣接関係が S1 内のフュージョン ルータとディス

トリビューション レイヤ スイッチ内の VRF 間に確立されます。

D1D1 #sh ip ospf 4 neighbor Neighbor ID Pri State Dead Time Address Interface10.122.233.4 1 FULL/BDR 00:00:03 10.122.35.34 TenGigabitEthernet1/1.63210.136.4.2 1 FULL/BDR 00:00:03 10.136.103.2 Vlan105310.136.100.2 1 FULL/DR 00:00:03 10.136.103.5 Vlan105310.136.4.2 1 FULL/DR 00:00:03 10.136.0.33 TenGigabitEthernet1/3.53210.122.233.5 1 FULL/DR 00:00:03 10.122.35.38 TenGigabitEthernet1/2.732

D2D2 #sh ip ospf 4 neighbor Neighbor ID Pri State Dead Time Address Interface10.122.233.4 1 FULL/BDR 00:00:03 10.122.35.36 TenGigabitEthernet1/1.73210.136.4.1 1 FULL/DROTHER 00:00:03 10.136.103.3 Vlan105310.136.100.2 1 FULL/DR 00:00:03 10.136.103.5 Vlan105310.136.4.1 1 FULL/BDR 00:00:03 10.136.0.32 TenGigabitEthernet1/3.532

41ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

10.122.233.5 1 FULL/DR 00:00:03 10.122.35.38 TenGigabitEthernet1/2.632

VRF がお互いにピアリングし、さらに S1 内のフュージョン ルータと SVI 1053 経由でピアリング

することに注意してください。また、それらはお互いにピアリングし、（Ten1/1、Ten1/2、および Ten1/3 のサブインスタンス経由で）コアに配置されたデバイスともピアリングします。

S1S1#sh ip ospf 100 neighborNeighbor ID Pri State Dead Time Address Interface10.136.100.2 1 FULL/BDR 00:00:03 10.136.200.2 Vlan20010.136.3.1 1 2WAY/DROTHER 00:00:03 10.136.103.3 Vlan90310.136.3.2 1 FULL/BDR 00:00:03 10.136.103.2 Vlan90310.136.100.2 1 FULL/DR 00:00:03 10.136.103.5 Vlan903

S2S2#sh ip ospf 100 neighbor Neighbor ID Pri State Dead Time Address Interface10.136.100.1 1 FULL/DR 00:00:03 10.136.200.1 Vlan20010.136.3.1 1 FULL/DROTHER 00:00:03 10.136.103.3 Vlan90310.136.3.2 1 FULL/BDR 00:00:03 10.136.103.2 Vlan90310.136.100.1 1 FULL/DROTHER 00:00:03 10.136.103.6 Vlan903

S1 および S2 は、ディストリビューション レイヤ デバイスの D1 と D2 上に定義された VRF と SVI 903 経由でピアリングします。サービス スイッチ間でレイヤ 3 のピアリングを確立するため

に、別の SVI 200 が定義されます。このピアリングは、特定の障害シナリオにおいて、共有サービ

スからキャンパス コアに向けてトラフィックを再ルーティングする場合に使用される可能性があ

ります。

2. 各 VPN にデフォルト ルートを通知するようにフュージョン ルータを設定：すでに述べたように、

定義された各 VPN が、特定の VPN に関連して宛先が不明である場合は常に、トラフィックをこ

の中央のロケーションに向けるようにするのが目的です。ここでは、デフォルト ルートがフュー

ジョン ルータのルーティング テーブルに存在することが前提です。これは、フュージョン ルータ

がその情報をネクストホップ ルータから学習するか（これは、たとえばインターネット エッジを

配置する場合）、静的に定義されているためです。望ましい動作になるような設定を次に示します

（これは、S1 と S2 両方のデバイスに当てはまります）。

S1router ospf 100 vrf fusion router-id 10.136.100.1 default-information originate metric 10 metric-type 1

S2router ospf 100 vrf fusion router-id 10.136.100.2 default-information originate metric 20 metric-type 1

上記の例では、default-information originate コマンドを利用してデフォルト ルートを挿入しま

す。このコマンドでは、デフォルト ルートが実際にはフュージョン ルータのルーティング テーブ

ルにない場合にそれを通知できるようにする always キーワードも提供されることに注意してくだ

さい。ディストリビューション スイッチにおける上記の特定の設定による結果を次に示します。

D1D1#show ip route vrf Red supernets-only Routing Table: RedCodes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

42ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static routeGateway of last resort is 10.136.103.6 to network 0.0.0.0O*E1 0.0.0.0/0 [110/20] via 10.136.103.6, 00:09:13, Vlan1053

D2D2#show ip route vrf Red supernets-only Routing Table: RedCodes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.136.103.6 to network 0.0.0.0O*E1 0.0.0.0/0 [110/20] via 10.136.103.6, 00:00:00, Vlan1053

前述のように、D1 と D2 は、それらのルーティング テーブルの中に S1 内のフュージョン ルータ

から受信したデフォルト ルートをインストールします。図 17 に結果的なトラフィック フローを示

しました。

ディストリビューション VRF もフュージョン ルータから別の VPN のプレフィクス情報を受信す

ることは注目に値します。EIGRP の配置オプションについて説明した際にすでに述べたように、

フュージョン ルータでは、すべてのキャンパス プレフィクスの完全な VPN 間のビューが可能で

す。OSPF では、フュージョン ルータによって通知されたルーティング情報をフィルタリングでき

ないように、同じエリアに属するすべてのルータが OSPF データベースと同期することが要求され

ます。選択されたルータだけ（次の例では、デフォルト ルート）がルーティング テーブルにイン

ポートされるように受信側の配信 VRF 上の配信リストを設定することをお勧めします（次の設定

例は、D1 と D2 の両方に有効）。

router ospf 4 vrf Red distribute-list Default in Vlan1053!ip access-list standard Default permit 0.0.0.0

OSPF コンバージェンスの結果

前に説明した別の障害シナリオでのコンバージェンスの結果を次にまとめます。

テスト 1 （S1 と D1 間の光ファイバの障害）

• コアからサービスへのフロー：<1 秒

この値は、S1 へ接続する光ファイバ リンクの障害が D1 デバイスによって検知される速度によっ

て決まります。これにより、SVI 1053 が DOWN 状態になり、その結果、ルーティング テーブル

からそのインターフェイス経由で学習したデフォルトのルートが削除されます。

• サービスからコアへのフロー：<1 秒

EIGRP の動作とは異なり、S1 内のフュージョン ルータは、ルーティング ピアリングが期限切れ

になる前に D1 内の VRF から学習したルートを削除できます。これにより、以下に示すようにこ

のコンバージェンス イベントをサブセカンドに抑えることができます。

Dec 9 16:13:10.414 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/23, changed state to downDec 9 16:13:10.418 EST: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet2/23, changed state to downDec 9 16:13:10.422 EST: %LINK-SP-3-UPDOWN: Interface GigabitEthernet2/23, changed state to down

43ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

Dec 9 16:13:10.426 EST: %LINK-3-UPDOWN: Interface GigabitEthernet2/23, changed state to downDec 9 16:13:10.806 EST: RT(fusion): del 10.137.42.0/24 via 10.136.104.3, ospf metric [110/23]Dec 9 16:13:13.374 EST: %OSPF-5-ADJCHG: Process 100, Nbr 10.136.4.1 on Vlan904 from 2WAY to DOWN, Neighbor Down: Dead timer expired

テスト 2 （S1 と共有サービス エリア間の光ファイバの障害）

• コアからサービスへのフロー：<1 秒

S1 内のフュージョン ルータ宛てのすべてのトラフィック フローを、トランジット リンク越しに S2 へ再ルーティングする必要があります。再ルーティングによって、通常、サブセカンドの中断

時間が生じます。

• サービスからコアへのフロー：<1 秒

共有サービス エリアからのトラフィックは、S2 内のフュージョン ルータが共有サービスのサブ

ネット（VLAN 32）上でアクティブな HSRP デバイスになるまで、ブラックホールに入ってしま

います。サブセカンドの HSRP タイマーを設定すると、このコンバージェンス イベントがサブセ

カンド以内に収まります。

テスト 3 （ファイアウォールの障害）

• コアからサービスへのフロー： ～ 4、5 秒

• サービスからコアへのフロー： ～ 4、5 秒

前述のトラフィックの中断時間の一因となる 2 つの主要なコンポーネント：

– S2 内のファイアウォールがアクティブな役割を担うまでに必要な時間：これは現在、FWSM の配置では 3 秒未満に設定できません。

– OSPF タイマーがアグレッシブに設定される場合、隣接関係がリセットされる可能性がありま

す（新しいファイアウォールがトラフィックを送信し始めるのに必要な 3 秒が与えられた場

合）。OSPF のピアリングを再確立するのに必要な時間を考慮する必要があるので、全体の中

断時間は 4 ～ 5 秒になります。OSPF の隣接関係がリセットされないようにするには、OSPF タイマーのアグレッシブ設定を低めにできます。これにより、OSPF の不感時間が、トラ

フィックの全体的な中断時間を決める主な要因になるような場合、障害シナリオ（たとえば、

光ファイバの障害のシナリオ）の復旧時間に影響が及んでしまうことに注意してください。

テスト 4 （サービス スイッチの障害）

• コアからサービスへのフロー： ～ 4、5 秒

• サービスからコアへのフロー： ～ 4、5 秒

前述のファイアウォールの障害のシナリオにおける考慮事項がここでも当てはまります。

テスト 5 （ディストリビューション スイッチの障害）

• コアからサービスへのフロー：<1 秒

この場合の復旧メカニズムは、ディストリビューション スイッチに障害が発生した場合の、コア デバイスからの ECMP になります。障害が発生するスイッチに直接接続されているコア デバイス

上でリンク検知メカニズムが適切に機能している場合、これは非常に高速に行われます。

• サービスからコアへのフロー： ～ 4 秒

復旧時間は、OSPF デッド タイマーに依存します。S1 上のフュージョン ルータ（アクティブな HSRP デバイス）が、次に示すように OSPF ピアリングを削除するまで障害の発生したスイッチ内

の VRF へトラフィックを送信し続けるためです。

Dec 9 16:42:56.666 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/23, changed state to down

44ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

Dec 9 16:42:56.674 EST: %LINK-3-UPDOWN: Interface GigabitEthernet2/23, changed state to downDec 9 16:42:56.666 EST: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet2/23, changed state to downDec 9 16:42:56.674 EST: %LINK-SP-3-UPDOWN: Interface GigabitEthernet2/23, changed state to downDec 9 16:42:59.990 EST: %OSPF-5-ADJCHG: Process 100, Nbr 10.136.4.1 on Vlan904 from 2WAY to DOWN, Neighbor Down: Dead timer expiredDec 9 16:43:00.014 EST: RT(fusion): del 10.137.32.0/24 via 10.136.103.3, ospf metric [110/23]

VRF およびフュージョン ルータ間での eBGP の使用

ディストリビューション スイッチ（D1 および D2）上に定義された VRF とフュージョン ルータ間の

ピアリングにおける eBGP の使用は、ほとんどの場合 MPLS VPN パス分離と併せて使用されます。主

な理由は、MPLS VPN では、PE デバイス間で VPN のルート情報を交換するのに MP-iBGP ルーティ

ング プロトコルが使用されるからです。図 12 で示したネットワークの例では、ディストリビューショ

ン レイヤ スイッチが PE の役割を果たします。つまり、iBGP が設定されています。そのため、フュー

ジョン ルータとの eBGP ピアリングを確立したり、ルートの交換を開始したりするのに、簡単に eBGP 設定をスイッチに追加できます（ルーティング プロトコルの再配布は必要なし）。

（注） パス分離の代替手段としての MPLS VPN の配置に関する詳細については、

http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/PathIsol.html を参照し

てください。

必要な設定手順を次に示します。

1. ファイアウォール コンテキストを越えて eBGP 隣接関係が確立できるようにします。フュージョ

ン ルータとディストリビューション VRF に必要な設定を次に示します。

D1router bgp 200 timers bgp 2 10 ! address-family ipv4 vrf Red neighbor 10.136.103.5 remote-as 100 neighbor 10.136.103.5 activate neighbor 10.136.103.6 remote-as 100 neighbor 10.136.103.6 activate maximum-paths 2 no synchronization bgp router-id 10.136.200.1 exit-address-family

D2router bgp 200 timers bgp 2 10 ! address-family ipv4 vrf Red neighbor 10.136.103.5 remote-as 100 neighbor 10.136.103.5 activate neighbor 10.136.103.6 remote-as 100 neighbor 10.136.103.6 activate maximum-paths 2 no synchronization bgp router-id 10.136.200.2 exit-address-family

45ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

S1router bgp 100 timers bgp 2 10 ! address-family ipv4 vrf fusion neighbor 10.136.103.2 remote-as 200 neighbor 10.136.103.2 activate neighbor 10.136.103.3 remote-as 200 neighbor 10.136.103.3 activate neighbor 10.136.103.5 remote-as 100 neighbor 10.136.103.5 activate maximum-paths 2 no synchronization bgp router-id 10.136.100.1 exit-address-family

S2router bgp 100 timers bgp 2 10 ! address-family ipv4 vrf fusion neighbor 10.136.103.2 remote-as 200 neighbor 10.136.103.2 activate neighbor 10.136.103.3 remote-as 200 neighbor 10.136.103.3 activate neighbor 10.136.103.6 remote-as 100 neighbor 10.136.103.6 activate maximum-paths 2 no synchronization bgp router-id 10.136.100.2 exit-address-family

上の設定例に関するいくつかの考慮事項：

– eBGP セッションは、図 15 で示した設計方針に従って、フュージョン ルータとディストリ

ビューション VRF 間でフルメッシュ構造を使用して確立されます。

– 追加の iBGP ピアリングがフュージョン ルータ間で確立されます。これは、フュージョン ルータが共有サービス エリアとの直接接続が切れてしまうような障害シナリオにおいて、再

ルーティング機能を提供するのに必要です。

– EIGRP と OSPF のシナリオで説明したのと同様に、特定の障害シナリオにおいて中断時間の

長さを短縮するために eBGP でもタイマーの調整が必要です。違いとしては、eBGP では、タ

イマーを低く設定し過ぎないことが重要なことです。確立されたセッションが切れる（たとえ

ば、ファイアウォールのフェールオーバー シナリオなど）場合、eBGP ではピアリング セッ

ションの確立やルーティング情報の交換が比較的遅いので、中断時間は実際は長くなってしま

います（40 秒以上）。上記の設定（キープアライブに 2 秒、保持時間に 10 秒）は、そのよう

なイベントから保護するには十分に控えめな値です。

– maximum-paths 2 コマンドは、フュージョン ルータが両方のディストリビューション VRF から受信した（逆の場合も同じ）ルーティング情報をルーティング テーブルに確実にインス

トールするのに必要です。

eBGP ピアリング セッションが正常に確立されるようにするためには、次に示すようにこれらのパ

ケットがファイアウォールを通過できるようにする必要があります。

access-list <ACL_NAME> extended permit tcp any any eq bgp

前の設定手順の結果、次で示すように、eBGP セッションが S1 内のフュージョン ルータとディス

トリビューション レイヤ スイッチ内の VRF 間に確立されます。

D1

46ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

D1#sh ip bgp vpnv4 vrf Red summary BGP router identifier 10.136.200.1, local AS number 200<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.103.5 4 100 37058 37167 1167515 0 0 13:50:39 110.136.103.6 4 100 37051 37173 1167515 0 0 13:50:39 1

D2D2#sh ip bgp vpnv4 vrf Red summaryBGP router identifier 10.136.200.2, local AS number 200<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.103.5 4 100 40552 40591 3596185 0 0 23:04:08 110.136.103.6 4 100 143455 143543 3596185 0 0 18:02:45 1

S1S1#sh ip bgp vpnv4 vrf fusion summaryBGP router identifier 10.136.100.1, local AS number 100<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.103.2 4 200 38649 38597 2957809 0 0 18:06:11 3210.136.103.3 4 200 38298 38203 2957809 0 0 14:07:05 3210.136.103.5 4 100 2173448 2171218 2957809 0 0 18:06:08 89

S2cr15-6500-2#sh ip bgp vpnv4 vrf fusion summaryBGP router identifier 10.136.100.2, local AS number 100<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.103.2 4 200 42475 42462 9446857 0 0 23:09:16 3210.136.103.3 4 200 143736 143590 9446857 0 0 14:08:46 3210.136.103.6 4 100 6534446 6510120 9446857 0 0 18:07:50 90

S1 および S2 は、ディストリビューション レイヤ デバイスの D1 と D2 上に定義された VRF と eBGP 経由でピアリングしますが、それらの間には、直接の iBGP セッションも確立されていま

す。この後者のピアリングは、特定の障害シナリオにおいて、共有サービスからキャンパス コア

に向けてトラフィックを再ルーティングする場合に使用される可能性があります。

2. 各 VPN にデフォルト ルートを通知するようにフュージョン ルータを設定：すでに述べたように、

定義された各 VPN が、特定の VPN に関連して宛先が不明である場合は常に、トラフィックをこ

の中央のロケーションに向けるようにするのが目的です。ここでは、デフォルト ルートがフュー

ジョン ルータのルーティング テーブルに存在することが前提です。これは、フュージョン ルータ

がその情報をネクストホップ ルータから学習するか（これは、たとえばインターネット エッジを

配置する場合）、静的に定義されているためです。望ましい動作になるような設定を次に示します。

S1router bgp 100 ! address-family ipv4 vrf fusion neighbor 10.136.105.2 remote-as 200 neighbor 10.136.105.2 activate neighbor 10.136.105.2 default-originate route-map default_only neighbor 10.136.105.2 route-map default_only out neighbor 10.136.105.3 remote-as 200 neighbor 10.136.105.3 activate neighbor 10.136.105.3 default-originate route-map default_only neighbor 10.136.105.3 route-map default_only out exit-address-family! ip access-list standard Default

47ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

permit 0.0.0.0!route-map default_only permit 10 match ip address Default set metric 10

S2router bgp 100 ! address-family ipv4 vrf fusion neighbor 10.136.105.2 remote-as 200 neighbor 10.136.105.2 activate neighbor 10.136.105.2 default-originate route-map default_only neighbor 10.136.105.2 route-map default_only out neighbor 10.136.105.3 remote-as 200 neighbor 10.136.105.3 activate neighbor 10.136.105.3 default-originate route-map default_only neighbor 10.136.105.3 route-map default_only outexit-address-family!ip access-list standard Default permit 0.0.0.0!route-map default_only permit 10 match ip address Default set metric 20

上記の例では、default-originate neighbor コマンドを利用してデフォルト ルートを挿入します。

デフォルト ルートだけがディストリビューション VRF に通知されるようにするために、追加の route-map が各ネイバーに適用されることに注意してください。route-map default-only をもっと

詳しく見ると、さらに S2 が、S1 よりも上位のメトリックをデフォルト ルートに設定する方法に

気付きます。これは、共有サービス エリアに対して S1 が常に優先されるネクストホップになるよ

うに実行されます（図 17 で示した設計方針を参照してください）。

ディストリビューション スイッチにおける上記の特定の設定による結果を次に示します。

D1D1#show ip route vrf Red supernets-only Routing Table: RedCodes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static routeGateway of last resort is 10.136.103.6 to network 0.0.0.0B* 0.0.0.0/0 [20/10] via 10.136.103.6, 00:20:11

D2D2#show ip route vrf Red supernets-only Routing Table: RedCodes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static routeGateway of last resort is 10.136.103.6 to network 0.0.0.0B* 0.0.0.0/0 [20/10] via 10.136.103.6, 00:20:11

48ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

前述のように、D1 と D2 は、それらのルーティング テーブルの中に S1 内のフュージョン ルータから

受信したデフォルト ルートをインストールします。結果的なトラフィック フローを図 17 に示します。

eBGP コンバージェンス結果

前に説明した別の障害シナリオでのコンバージェンスの結果を次にまとめます。

テスト 1 （S1 と D1 間の光ファイバの障害）

• コアからサービスへのフロー：<1 秒

この値は、S1 へ接続する光ファイバ リンクの障害が D1 デバイスによって検知される速度によっ

て決まります。これにより、SVI 1053 が DOWN 状態になり、その結果、ルーティング テーブル

からそのインターフェイス経由で学習したデフォルトのルートが削除されます。

• サービスからコアへのフロー： ～ 9、10 秒

この値は、フュージョン ルータが D1 から学習したルートをルーティング テーブルから削除でき

る速度によって決まります。前述したように、SVI は D1 上で DOWN 状態なので、ルートが削除

されるまでトラフィックはブラックホールに入ってしまいます。この検知の主な要因は、設定され

た BGP の保持時間です。この値は、別の障害シナリオにおいてピアリングが切断されるのを避け

るために、10 秒未満には変更しないでください（切断されると、40 秒以上中断されてしまいま

す）。この動作は、S1 内のフュージョン ルータ上で取得された次の出力のようになります。

Dec 9 16:53:57.780 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/23, changed state to downDec 9 16:53:57.788 EST: %LINK-3-UPDOWN: Interface GigabitEthernet2/23, changed state to downDec 9 16:53:57.784 EST: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet2/23, changed state to downDec 9 16:53:57.788 EST: %LINK-SP-3-UPDOWN: Interface GigabitEthernet2/23, changed state to downDec 9 16:54:07.840 EST: %BGP-5-ADJCHANGE: neighbor 10.136.103.3 vpn vrf fusion Down BGP Notification sentDec 9 16:54:07.840 EST: %BGP-3-NOTIFICATION: sent to neighbor 10.136.103.3 4/0 (hold time expired) 0 bytes Dec 9 16:54:07.840 EST: RT(fusion): del 10.137.32.0/24 via 10.136.103.3, bgp metric [20/3584]

前述のように、S1 内のフュージョン ルータと D1 内の VRF 間の BGP のピアリングが削除される

と、BGP の保持時間の期限が切れるため、リモート宛先（10.137.32.0）へのルートが削除されま

す。

テスト 2 （S1 と共有サービス エリア間の光ファイバの障害）

• コアからサービスへのフロー：<1 秒

S1 内のフュージョン ルータ宛てのすべてのトラフィック フローを、トランジット リンク越しに S2 へ再ルーティングする必要があります。再ルーティングによって、通常、サブセカンドの中断

時間が生じます。

• サービスからコアへのフロー：<1 秒

共有サービス エリアからのトラフィックは、S2 内のフュージョン ルータが共有サービスのサブ

ネット（VLAN 32）上でアクティブな HSRP デバイスになるまで、ブラックホールに入ってしま

います。サブセカンドの HSRP タイマーを設定すると、このコンバージェンス イベントがサブセ

カンド以内に収まります。

テスト 3 （ファイアウォールの障害）

• コアからサービスへのフロー：～ 3、4 秒

• サービスからコアへのフロー：～ 3、4 秒

49ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

上記のトラフィックの中断時間は、S2 内のファイアウォールがアクティブな役割を担うようにな

るまでに必要な時間が原因です。これは現在、FWSM の配置では 3 秒未満に設定できません。

テスト 4 （サービス スイッチの障害）

• コアからサービスへのフロー： ～ 9、10 秒

この中断時間は、すべてのフローに影響を及ぼし、ディストリビューション VRF が S1 内の

フュージョン ルータに障害が発生したことを認識するまで、そのルータにトラフィックを送信し

続けるために起こります。この状態は、上記の値に復旧時間を設定する BGP の保持時間の期限切

れによってだけ表されます。

• サービスからコアへのフロー： ～ 9、10 秒

S1 に障害が発生すると、S1 にトラフィックを配信するのにレイヤ 2 パスは利用できなくなるの

で、共有サービス エリアからのフロー（D1 内の VRF 宛てのフロー）の半分は、9 ～ 10 秒間中断

されます。フローの残り半分は、D2 内の VRF に送信され、S2 内の FWSM がアクティブになるの

に必要な時間によって、およそ 3 ～ 4 秒間だけ中断されます。

テスト 5 （ディストリビューション スイッチの障害）

• コアからサービスへのフロー：<1 秒

この場合の復旧メカニズムは、ディストリビューション スイッチに障害が発生した場合の、コア デバイスからの ECMP になります。障害が発生するスイッチに直接接続されているコア デバイス

上でリンク検知メカニズムが適切に機能している場合、これは非常に高速に行われます。

• サービスからコアへのフロー： ～ 9、10 秒

復旧時間は、ここでも BGP 保持時間に依存します。S1 上のフュージョン ルータ（アクティブな HSRP デバイス）が、eBGP ピアリングを削除するまで障害の発生したスイッチ内の VRF へトラ

フィックを送信し続けるためです。

ルーテッド モードで配置されたファイアウォール コンテキスト

ファイアウォール コンテキストをルーテッド モードで配置する場合、コンテキストに関するルーティ

ング プロトコルがサポートされていないということが、現在の制限事項です（Cisco ファイアウォール

では、仮想かされていない場合（つまり、シングル コンテキストモード）だけ、ルーテッド モードで

のルーティング プロトコルをサポートします）。このマニュアルとの関連で推奨される方法としては、

図 24 に示すように、eBGP を利用してフュージョン ルータとディストリビューション レイヤで定義さ

れているさまざまな VRF 間でルーティング情報を交換できるようにする方法が挙げられます。

50ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 24 ルーテッド モードでのファイアウォール コンテキストとのルーティング ピアリング

（注） 代わりの方法としては、VRF、ファイアウォール コンテキスト、およびフュージョン ルータ間で単純

に静的ルーティングを使用する方法が挙げられます。この方法は、特定のシナリオ、特に冗長サイトに

サービス エッジ機能を配置する場合は、トラフィックがブラックホールに入ってしまう可能性がある

ので推奨されません。

ルーテッド モードで配置されたファイアウォールを使用するサービス エッジ用に推奨される配置モデ

ルを図 25 に示します。

RedVPN

GreenVPN

YellowVPN

L3L3 L3

eBGP

2262

65

51ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 25 ルーテッド モードでのファイアウォール コンテキストの例

トランスペアレント モードによるファイアウォール コンテキストの配置との関連で、このネットワー

ク トポロジを図 14 のトポロジと比較する場合は、次のことに注意してください。

• 各ファイアウォール コンテキストは、ネットワーク内でルーテッド ホップになります。これは、

VLAN の内部および外部のファイアウォールが異なる 2 つの IP サブネットに属するようになるこ

とを意味します。

• HSRP は、 適な First Hop Redundancy Protocol で、次のインターフェイス用に仮想ゲートウェ

イ機能を提供するのに利用されます。

– 共有サービス サブネット（VLAN 32）：これは、フュージョン デバイスに直接接続されてい

るサブネット内に共有サービスが配置されていることが前提です。

– サブネット内のファイアウォール（Red VPN には VLAN 903、Green VPN には VLAN 904）。

– サブネット外のファイアウォール（Red VPN には VLAN 1053、Green VPN には VLAN 1054）。

D1 D2

.3

.3

.2

.2

10.136.0.42/30

.33 .34

.43 .44

S1 S2VLAN 903 10.136.113.0/24 VLAN 904 10.136.114.0/24

VLAN 1054 10.136.104.0/24VLAN 1053 10.136.103.0/24

HSRP VIP .1VLAN 903 904

HSRP VIP .1VLAN 1053 1054

.3 .2.3 .2

.5

.5

.5

.5

.4

.4

.4

.4

VLAN 32 10.136.32.0/24

HSRP VIP .1

10.136.200.0/30.1 .2

Red VPN

Green VPN

10.136.0.32/30

2262

66

52ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

• ディストリビューション レイヤ スイッチ内に配置されたフュージョン ルータおよび VRF は、

ルーテッド リンクにそのまま接続されています。これは、特定の障害状態において、トラフィッ

クの再ルーティングを行うのに使用されるレイヤ 3 パスを提供するためのものです（後ほど説明し

ます）。

• 透過的なファイアウォールの配置の場合、フュージョン ルータによって、インターフェイス（ま

たは SVI）が各キャンパス VPN 専用になるように定義されます。

適なルーティング プロトコルが通過できるように各ファイアウォール コンテキスト上のポリシーが

適切に配置されている場合には（eBGP に必要な設定は、このマニュアルのプロトコル特有のセクショ

ンで後ほど説明されます）、図 26 で示すように、ディストリビューション スイッチ内で定義された VRF が両方のフュージョン ルータとピアリングします。

図 26 フルメッシュのルーティング ピアリング

特定のルーティング ドメイン内で宛先が不明である場合は、各 VPN が常にトラフィックをサービス エッジに向けるようにしたいので、通常の配置では、フュージョン ルータは、D1 および D2 内で定義

されている各 VRF にデフォルト ルートを通知するだけになります。同時に、各 VRF は、リモート キャンパスのサブネットをフュージョン ルータに通知します。結果的に、コアと共有サービス エリア

間のトラフィックは、図 27 で説明されるパスをデフォルトで流れることになります。

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPN

S2S1

2262

56

53ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 27 デフォルトのトラフィック フロー

この動作の原因は、次の例で示すように、ファイアウォール モジュールがネットワーク内のルーテッ

ド ホップになり、設定が必要な静的ルーティング情報に基づいてトラフィックをルーティングするた

めです。

route outside-vrf6 10.137.0.0 255.255.0.0 10.136.113.1 route inside-vrf6 0.0.0.0 0.0.0.0 10.136.103.1

上記の設定例では、10.137.0.0/16 は、キャンパス内部の特定の Red VPN が使用するアドレス空間のす

べてを表します。その結果、ファイアウォールがキャンパス コア内から発信された共有サービス エリ

ア宛てのトラフィックを受信するたびに、HSRP VIP のアドレスである 10.136.113.1 （VLAN 1053 上）がネクストホップとして使用されます。同様に、逆方向のトラフィック フローには、HSRP VIP のアドレス 10.136.103.1 （VLAN 903 上）が使用されます。両方のサブネット（設計上 S1 と D1）上

のアクティブ デバイスには、これらのフローを受信してルーティングする責任があります。

この後セクションでは、異なる障害シナリオにおける動作について説明します。後のプロトコル特有の

セクションでは、eBGP の配置に関して、具体的な復旧方法と復旧時間について分析します。

（注） マニュアルのこの部分における冗長性に関する話題は、シングル サイトの配置での復旧方法に焦点が

当てられます。冗長サイトの考慮事項に関しては、「仮想ネットワークにおけるサイト冗長性の計画」 を参照してください。

コンバージェンス分析

ディストリビューション スイッチとサービス スイッチ間の光ファイバ障害

D1 と S1 間の光ファイバによる接続に障害が発生すると、D1 内の VRF とフュージョン ルータ間のピ

アリングが削除されます。さらに、VLAN 1053 外のファイアウォール上で D2 がアクティブな HSRP デバイスになります。トラフィック フローに影響する結果を、図 28 に示します。

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPNRed VPN

S2S1 S2S1

HSRP

HSRP HSRP

2262

67

54ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 28 D1 と S1 間の光ファイバ障害後のトラフィック フロー

• コアからサービスへのフロー：D1 は、フュージョン ルータからデフォルト ルート（または、共有

サービス サブネット用のより具体的なルート）を受信するのを停止します。その結果、その情報

の D1 からキャンパス コアへの通知が停止されるので、コアから共有サービス エリアに向けられ

たすべてのトラフィックが D2 に配信されるようになります。この場合に発生するコンバージェン

スは、D1 が光ファイバの障害を検知し、コアへのルーティング情報を停止する速さに基づきます。

リンク障害検出が機能する場合、これは非常に高速で、サブセカンドの中断時間しか生じません。

• サービスからコアへのフロー：光ファイバの障害とは関係なしに、共有サービス サブネット

（VLAN 32）上で S1 内のフュージョン ルータが HSRP としてのアクティブな役割を維持します。

光ファイバに障害が発生すると、サブネット（VLAN 1053）外のファイアウォール上で D2 がア

クティブな HSRP デバイスになり、その瞬間からファイアウォールがすべてのトラフィック フローを D2 内の VRF へ送信し始めます。コンバージェンスの観点からすると、ここで中断時間の

長さを決定する主な要因は、D2 が HSRP のアクティブな役割を獲得するのに要する時間です。こ

の値をサブセカンドに維持するには、次に示すように HSRP タイマーをアグレッシブに設定する

必要があります。

D1interface Vlan1053 description Firewall Outside VRF Red ip vrf forwarding Red ip address 10.136.103.3 255.255.255.0 standby 1 ip 10.136.103.1 standby 1 timers msec 250 msec 750 standby 1 priority 105 standby 1 preempt delay minimum 180

D2interface Vlan1053 description Firewall Outside VRF Red ip vrf forwarding Red ip address 10.136.103.2 255.255.255.0

S2

S1 S2S1

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPNRed VPN

HSRP

HSRP

2262

68

55ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

standby 1 ip 10.136.103.1 standby 2 timers msec 250 msec 750

（注） 150 以下の VLAN の配置では、サブセカンド HRSP タイマーの使用をお勧めします。詳細については、

次のキャンパス デザイン ガイドを参照してください。http://www.cisco.com/en/US/netsol/ns815/networking_solutions_program_home.html

サービス スイッチと共有サービス エリア間の光ファイバ障害

サービス スイッチ S1 を共有サービス エリアに接続している光ファイバ リンクに障害が発生しても、

VRF とフュージョン ルータ間のルーティング ピアリングには変化はありません。トラフィック フロー

は、図 29 で示すようになります。

図 29 S1 と共有サービス エリア間の光ファイバ障害後のトラフィック フロー

• コアからサービスへのフロー：S1 内のフュージョン ルータは、光ファイバに障害が発生したとし

ても、サブネット（VLAN 903）内のファイアウォール上でアクティブな HSRP デバイスのままに

なります（これは、HRSP メッセージがサービス スイッチ間でポートチャネル越しに交換される

ためです）。これは、共有サービス エリアにある宛先に到達するには、トランジット リンク越しに

トラフィックを再ルーティングする必要があることを意味します。

• サービスからコアへのフロー：S2 内のフュージョン ルータが 共有サブネット（VLAN 32）上で

アクティブな HSRP デバイスになり、アクティブなファイアウォールがそのデバイス内にあるの

で、すべてのトラフィック フローをトランジット リンク越しに S1 に送信する必要があります。そ

の後、サブネット（VLAN 1053）外のファイアウォール上のアクティブな HSRP デバイスである D1 内の VRF に、すべてのフローが配信されます。

推奨設計：図 20 で示したトランジット リンク越しの準 適なパスを避けるために、可能であれば各

サービス スイッチおよび共有サービス エリア間にポートチャネルを配置することをお勧めします。

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPN

S2S1 S2S1

Red VPN

HSRP HSRP

HSRP

2262

69

56ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

アクティブなファイアウォール モジュールの障害

S1 内でファイアウォール モジュールに障害が発生すると、VRF およびフュージョン ルータは、S2 内部で新しくアクティブになったファイアウォールによってルーティング ピアリングを保持します。結

果的に生じるトラフィック フローを図 30 に示します。

図 30 ファイアウォールの障害後のトラフィック フロー

• コアからサービスへのフロー：ファイアウォールの障害とは関係なしに、サブネット（VLAN 903）内のファイアウォール上で S1 が HSRP としてのアクティブな役割を維持します。これは、

S2 のファイアウォールがアクティブになった場合でも、すべてのトラフィックがそのまま S1 内の

フュージョン ルータに配信され、図 30 で示すトラフィック パターンを生じることを意味します。

これらのフローが確立されるまでの全体の中断時間は、主に S2 内のファイアウォールがアクティ

ブになるまでの時間に左右されます。これは、この時間よりも設定されたルーティング プロトコ

ルの保持時間が長いことが前提です。そうでない場合は、ファイアウォールのフェールオーバー時

間に加えて、ルーティング プロトコルのピアリングを再確立し、ルーティング情報を通知するの

に必要な時間を考慮する必要があります（さらに具体的な考慮事項については、この後のプロトコ

ル固有のセクションを参照してください）。S2 内のファイアウォール モジュールが他方のファイア

ウォールの障害を検知し、アクティブ デバイスになるのに必要な時間は、ファイアウォール間で

設定された保持時間に依存することに注意してください。FWSM では、次に示すように、保持時

間を 3 秒未満には設定できません。

FWSM(config)# failover polltime unit msec 500 holdtime ?configure mode commands/options: <3-45> Hold time in seconds, default is 3 X poll time but minimum is 3 Seconds

• サービスからコアへのフロー：ファイアウォールの障害とは関係なしに、共有サービス サブネッ

ト（VLAN 32）上で S1 がアクティブな HSRP デバイスのままになります。同時に、サブネット

（VLAN 1053）外のファイアウォール上で D1 内の VRF がアクティブな HSRP の役割を維持する

ので、共有サービス エリアから発信されるすべてのトラフィック フローはその VRF に配信されま

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPN

S2S1 S2S1

Red VPN

HSRP HSRP

HSRP

2262

70

57ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

す。この方向にかかる復旧時間には、前の箇条書き項目で説明したのと同じ考慮事項が当てはま

り、コンバージェンスは、ファイアウォールがフェールオーバーできる速度や、その間にデバイス

間のピアリングが切断したか否かに依存します。

推奨設計：S1 内部のファイアウォール モジュールが（動作中に）常にアクティブの役割を果たすよう

にファイアウォールの先取りを設定し、上記の準 適なトラフィック パスを回避するようにお勧めし

ます。

サービス スイッチの障害

この障害シナリオを図 31 に示します。

図 31 サービス スイッチの障害後のトラフィック フロー

サービス スイッチ S1 全体の障害のため、S1 内の VRF とフュージョン ルータ間のピアリングが削除さ

れます。結果的に、トラフィック フローは次のようになります。

• コアからサービスへのフロー：D2 と S2 間のリンクは、コアから共有サービスへの唯一利用可能

なパスです。コンバージェンスの観点からすると、中断時間はファイアウォールがアクティブにな

るまでの時間によって決まり、ルーティング ピアリングを連続的に確立できます。この中断時間

の実体は、ファイアウォールの障害のシナリオに関する以前のセクションで説明したものと同じで

あると考えることが可能です。

• サービスからコアへのフロー：フュージョン ルータは、D2 内の VRF 経由の、リモート キャンパ

スの宛先への有効なパスだけを持っています。S1 スイッチで障害が発生したために、S2 内の

フュージョン ルータが共有サービスのサブネット（VLAN 32）上でアクティブな HSRP デバイス

になります。復旧のメカニズムは、前の箇条書き項目内で説明したものと同じです。

ディストリビューション スイッチの障害

後の関連シナリオは、図 32 に示すように、ディストリビューション スイッチの障害です。

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPNRed VPN

S2S1 S2S1

HSRP HSRP

HSRP

2262

71

58ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 32 ディストリビューション スイッチの障害後のトラフィック フロー

トラフィック フローおよびルーティング ピアリングの観点からは、このシナリオは光ファイバ障害の

シナリオと非常に似ています。

• コアからサービスへのフロー：D1 スイッチ全体に障害が発生しているので、コア デバイスはそれ

を通過する有効なパスを削除し、すべてのトラフィックを D2 経由で再ルーティングします。前と

同様、リンク障害検出が機能する場合、これはサブセカンドの中断時間しか生じない ECMP の再

ルーティングです。

• サービスからコアへのフロー：S1 内部のファイアウォールは、すべてのトラフィック フローをサ

ブネット（VLAN 1053）外のファイアウォール上の HSRP VIP に送信し続けます。HSRP がアク

ティブになると、これらすべてのフローが D2 の VRF によってピックアップされます。停止の長

さは、このプロセスでかかる時間によって異なります。タイマーをサブセカンドに設定すると、こ

のコンバージェンス イベントがサブセカンド以内に収まります。

次のセクションでは、これまでに説明してきたすべての障害シナリオのコンバージェンス結果を含む、

eBGP の配置に関する特定の設計と設定上の考慮事項について説明します。

VRF およびフュージョン ルータ間での eBGP の使用

ルーテッド モードでファイアウォール コンテキストを配置するときに配信スイッチ（D1 および D2）とフュージョン ルータで定義される VRF 間でのピアリングで BGP を使用する場合の考慮事項は、ト

ランスペアレント モードのファイアウォールですでに行ったものと基本的に同じです（詳細について

は、対応するセクションを参照してください）。唯一の違いは、S1 では、経路の決定がファイアウォー

ルの内部サブネット（VLAN 903）上のアクティブな HSRP デバイスに基づいてルーテッド ファイア

ウォールによって行われるため、フュージョン ルータが 適なデフォルト経路を確実にアドバタイズ

するための要件が存在しないことです。

eBGP コンバージェンス結果

さまざまな障害シナリオで実現される収束結果を以下にまとめます。

テスト 1 （S1 と D1 間の光ファイバの障害）

S2

S1 S2S1

D2D1SiSi L3

L2

L2 L2

L2 L2

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPNRed VPN

HSRP

HSRP HSRP

2262

72

59ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

• コアからサービスへのフロー：<1 秒

この値は、S1 へ接続する光ファイバ リンクの障害が D1 デバイスによって検知される速度によっ

て決まります。これにより、SVI 1053 が DOWN 状態になり、その結果、ルーティング テーブル

からそのインターフェイス経由で学習したデフォルトのルートが削除されます。

• サービスからコアへのフロー：<1 秒

この値は、D2 上の VRF がサブネット（VLAN 1053）外のファイアウォールで HSRP をアクティ

ブできる早さによって決定されます。サブセカンドの HSRP タイマーを設定すると、復旧時間が

サブセカンド以内に収まります。

テスト 2 （S1 と共有サービス エリア間の光ファイバの障害）

• コアからサービスへのフロー：<1 秒

S1 内のフュージョン ルータ宛てのすべてのトラフィック フローを、トランジット リンク越しに S2 へ再ルーティングする必要があります。再ルーティングによって、通常、サブセカンドの中断

時間が生じます。

• サービスからコアへのフロー：<1 秒

共有サービス エリアからのトラフィックは、S2 内のフュージョン ルータが共有サービスのサブ

ネット（VLAN 32）上でアクティブな HSRP デバイスになるまで、ブラックホールに入ってしま

います。サブセカンドの HSRP タイマーを設定すると、このコンバージェンス イベントがサブセ

カンド以内に収まります。

テスト 3 （ファイアウォールの障害）

• コアからサービスへのフロー：～ 3、4 秒

• サービスからコアへのフロー：～ 3、4 秒

上記のトラフィックの中断時間は、S2 内のファイアウォールがアクティブな役割を担うようにな

るまでに必要な時間が原因です。これは現在、FWSM の配置では 3 秒未満に設定できません。

テスト 4 （サービス スイッチの障害）

• コアからサービスへのフロー：～ 3、4 秒

• サービスからコアへのフロー：～ 3、4 秒

上記のトラフィックの中断時間は、S2 内のファイアウォールがアクティブな役割を担うようにな

るまでに必要な時間が原因です。ファイアウォールがトランスペアレント モードで使用される eBGP 構成とは異なり、設定されている BGP のホールドタイムは、このケースで実現されるコン

バージェンス時間を決定する要素とはなりません。これは、ファイアウォール コンテキストがこ

こではホップにルートされており、常にサブネット内とサブネット外の両方のファイアウォールに

トラフィックを送信するためです。

テスト 5 （ディストリビューション スイッチの障害）

• コアからサービスへのフロー：<1 秒

この場合の復旧メカニズムは、ディストリビューション スイッチに障害が発生した場合の、コア デバイスからの ECMP になります。障害が発生するスイッチに直接接続されているコア デバイス

上でリンク検知メカニズムが適切に機能している場合、これは非常に高速に行われます。

• サービスからコアへのフロー：<1 秒

この停止は、D2 の VRF がサブネット（VLAN 1053）外のファイアウォールでアクティブな HSRP デバイスとなるのに必要な時間によって決定されます。繰り返しになりますが、HSRP タイ

マーをサブセカンドにして使用する場合は、停止時間にサブセカンド値を入力できます。

60ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

デュアル ティアの実装：概要と設計の推奨事項

このセクションで説明する大規模な配置でのデュアル ティア実装モデルは、VRF（ディストリビュー

ション レイヤ スイッチ）の終了機能を隔離しておくことにメリットがあり、サービス スイッチ上で

ファイアウォールとフュージョン ルータ サービスを提供できることで、推奨されています。

全体的なサービス エッジ設計の安定性のために、ディストリビューション レイヤとサービス スイッチ

の間に STP ループを作らないようにすることを推奨します。これは、これらのデバイスを U 字形でレ

イヤ 2 トランクに接続することで実現できます。この場合、ディストリビューション レイヤ スイッチ

間の接続はルーテッド リンクとして設定されます。

ファイアウォール コンテキストの動作モードによって、さまざまなルーティング プロトコルを利用し

て、フュージョン ルータとディストリビューション レイヤで定義される VRF 間のルーティング情報を

動的に交換できます。

• トランスペアレント モードのファイアウォール：EIGRP、OSPF、または eBGP

• ルーテッド モードのファイアウォール：eBGP

表 1 に、次の障害シナリオのもとで実現されるコンバージェンス結果をまとめています。

• テスト 1：サービス スイッチとディストリビューション スイッチ間のファイバ障害

• テスト 2：サービス スイッチと共有サービス エリア間のファイバ障害

• テスト 3：FWSM の障害

• テスト 4：サービス スイッチの障害

• テスト 5：ディストリビューション スイッチの障害

コンバージェンス結果の分析から、次の結論を導くことができます。

• eBGP を、ルーテッド モードで配置されているファイアウォール コンテキストと共に使用するこ

とを推奨します。復旧時間は、このシナリオでは次の 2 つの状況でだけサブセカンドになりませ

ん。

表 1 2 ティアモデルのコンバージェンス結果1

1. 太字の結果は、コアからサービスへのフローで、斜体 の結果はサービスからコアへのフローです。

テスト 1テスト 2 テスト 3 テスト 4 テスト 5

トランスペアレント モードでのファイアウォール コンテキスト

EIGRP<1 秒

～ 3 秒

<1 秒

<1 秒

～ 4-5 秒

～ 4.5 秒

～ 4-5 秒

～ 4-5 秒

<1 秒

～ 3 秒

OSPF<1 秒

<1 秒

<1 秒

<1 秒

～ 4-5 秒

～ 4.5 秒

～ 4-5 秒

～ 4-5 秒

<1 秒

～ 4 秒

eBGP<1 秒

～ 9-10 秒

<1 秒

<1 秒

～ 3-4 秒

～ 3-4 秒

～ 9-10 秒

～ 9-10 秒

<1 秒

～ 9-10 秒ルーテッド モードでのファイアウォール コンテキスト

eBGP<1 秒

<1 秒

<1 秒

<1 秒

～ 3-4 秒

～ 3-4 秒

～ 3-4 秒

～ 3-4 秒

<1 秒

<1 秒

61ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

– ファイアウォールの障害：このケースでコンバージェンスを決定する主要な要素は、ファイア

ウォールのホールドタイムです。現在、FWSM で設定可能な 小値は 3 秒ですが、将来のリ

リースではこれが改善される可能性があります。

– サービス スイッチの障害：ファイアウォールのホールドタイムもこのケースでコンバージェ

ンスに影響する主要な要素で、ここでも上記と同じ配慮がなされています。さらに、冗長化電

源の導入、スーパーバイザ機能の冗長化などにより、特定のデバイスの復元力を向上させるこ

とも可能です。

• IGP（EIGRP または OSPF）を、トランスペアレント モードのファイアウォールと併用すること

も推奨します。上記で行ったのと同様の考慮事項をここでも繰り返します。さらに、いくつかの障

害シナリオ（EIGRP でのテスト 1 および EIGRP と OSPF でのテスト 4）での復旧時間は、設定さ

れた IGP ホールドタイムによって決定されます。全体的な設計の安定性のためには、サブセカン

ド IGP タイマーを使用することは好ましくないため、この復旧時間を短縮する手段は限られてい

ます。

シングル ティアの実装

保護されたサービス アクセスを配置するための 2 番目のモデルでは、図 33 に示すようなシングル ティ

アの実装が必要となります。

62ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 33 シングル ティア実装モデル

このモデルでは、S1/D1 のネットワーク デバイスがディストリビューション スイッチとサービス スイッチの両方の役割を果たすため、すべての機能（VRF、ファイアウォール、フュージョン ルーティ

ング）が、同じ物理ネットワーク デバイス（S1/D1）で実行されます。仮想ネットワークでこれらのデ

バイスが果たす役割は、配置されているパス隔離戦略に大きく依存します。

• MPLS VPN デザインでは、これらのデバイスは PE として配置されます。

• VRF-Lite エンドツーエンド シナリオでは、これらは仮想化されたリンク経由でコアに接続されま

す（サブインターフェイスまたは レイヤ 2 トランクと SVI のいずれかを使用して）。

• VRF-Lite と GRE トンネルが配置されている場合は、これらのデバイスは、多くの場合、リモート スポークで開始された GRE トンネルを集約するハブとして機能します。

論理的な観点からは、VRF と互いに接続するレイヤ 3 リンクはもはや存在しないことに注目します。

これは、2 ティア モデルで、ループ化されたトポロジが作られるのを回避するために必要となります

が、ここではレイヤ 2 リンクだけが 2 つのスイッチ間のポートチャネルとなるため、便利ではありませ

ん。

シングル ティア配置ではさらにいくつかの考慮事項があります（2 ティア モデルで説明したものと同

様の考慮事項もあります）。

• このモデルでのフュージョン ルータ機能は、その機能を実行する隔離された物理デバイスを持つ

ことができないため、その目的専用の VRF を定義して実装する必要があります。

Red VPNRed VPN

Red VPND1 D2

S1 S2

3

Red VPN

Yellow VPN

Green VPN

HSRP

HSRP

HSRP

L2

L2 L2

S2/D2

S1/D1

2262

73

63ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

（注） デフォルトの VRF（aka グローバル テーブル）も、フュージョン ルーティング機能を実行す

るのに使用できます。

• フュージョン VRF は、レイヤ 3 接続のピアとして機能します。この機能は、サービス スイッチを

接続するレイヤ 2 ポートチャネル トランクに引き継がれる特定の VLAN を、この目的で指定する

ことで実現できます。

（注） 2 つのファイアウォール モジュール間で復元力の高い接続を提供するために、サービス スイッ

チ間にポートチャネルを使用することを強く推奨します。

• 各ファイアウォール コンテキストの内部インターフェイスは、フュージョン ルータ側になってお

り、外部インターフェイスは VRF 側になっています。この選択は、共有エリア内に配置された

サービスを保護するための要件によって決まります。

• VLAN の内部と外部のファイアウォールが、スイッチと HSRP 間に拡張されて、両方のサブネッ

トでデフォルト ゲートウェイ機能を提供するのに使用されます。

次のセクションでは、シングル ティア サービス エッジ モデルを配置するための、設計上の考慮事項と

設定ガイドラインに重点を置いて説明します。2 ティア配置ですでに説明したシナリオと設定がよく似

ているため、重要な違いだけを取り上げて説明します。

トランスペアレント モードで配置されたファイアウォール コンテキスト

2 ティア モデルの説明ですでに述べたように、ファイアウォール コンテキストをトランスペアレント モードで配置することで、すでに使用されている IP アドレスを変更することなく、ファイアウォール

をネットワークに挿入できるようになります。さらに、図 34 に示すように、 下部で定義されている VRF と 上部のフュージョン ルータの間で、さまざまなタイプのルーティング ピアリングを確立でき

ます。

64ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 34 トランスペアレント モードでのファイアウォール コンテキストとのルーティング ピアリング

この機能で使用されるルーティング プロトコルの種類は、通常は、採用されたパス分離方法によって

決まります。

• MPLS VPN 構成では、キャンパス インフラストラクチャ全域で VPN ルートを交換している PE デバイス間に iBGP がすでに存在するために、eBGP を使用するように推奨されます。

• VRF-Lite エンドツーエンド（または VRF-Lite + GRE）構成の場合は、通常は各仮想ネットワー

ク内ですでにコントロール プレーン プロトコルとして使用されている同じ IGP が、このタイプの

ピアリングでも利用されます。

トラフィック フローと復旧シナリオに関する考慮事項は、2 ティア配置で説明したものと同様です。こ

のケースでは、設計上 2 つのレイヤ 2 リンクしか存在しないため（サービス スイッチ間のトランジッ

ト リンク）、トラフィック フローは実際には簡略化されます。

次のシナリオでは、設定の観点からの違いを指摘して、EIGRP、OSPF、または eBGP を使用したルー

ティング ピアリングを可能にします。図 35 に示すように、その目的は 2 ティア設計の場合と同様に、

フルメッシュ ピアリングをフュージョン VRF と ファイアウォールの外側に定義されている VRF との

間に作成することです。

VPN

L2L2 L2

OSPF EiGRPeBGP

2262

54

65ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 35 フルメッシュのルーティング ピアリング

設定例はすべて図 36 のネットワーク トポロジ、特に Red VPN を参照しています。

L2

L2 L2

Red VPN

S2/D2S1/D1

2262

74

66ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 36 トランスペアレント モードのファイアウォール コンテキストの例

プロトコル固有の内容を説明する前に、3 つの配置（EIGRP、OSPF、および eBGP）すべてに適用さ

れる考慮事項と、デュアル ティア配置とシングル ティア配置の違いについて説明します。

• サブネット内とサブネット外のファイアウォールに対応する SVI は、同じデバイス（S1/D1 また

は S2/D2）内で定義する必要があります。これにより、これらの SVIをさまざまな VRF にマッピ

ングするための要件が適用されます。外部には Red VRF があり、内部にはフュージョン VRF（ま

たはグローバル テーブルをオプションで使用）があります。

• トランスペアレント モードで配置されているファイアウォール コンテキスト全体で、同じ物理デ

バイスの SVI 間で接続性を確立する場合は、ARP を適切に機能させるための追加の設定手順が必

要となります。この問題の根本的な原因は、次の例で示したように、デフォルトでは、Catalyst 6500 デバイスで定義されているすべての SVI が、同じ MAC アドレスを継承することにあります。

S1/D1S1/D1#sh int vlan 903Vlan903 is up, line protocol is up Hardware is EtherSVI, address is 000b.4594.1c00 (bia 000b.4594.1c00) Description: Firewall_Inside_Red<snip>S1/D1#sh int vlan 1053Vlan1053 is up, line protocol is up

.3

.3

.2

.2

S1/D1 S2/D2

VLAN 903 10.136.103.0/24 VLAN 904 10.136.104.0/24

VLAN 1054 10.136.104.0/24VLAN 1053 10.136.103.0/24

HSRP VIP .4VLAN 903 904

HSRP VIP .1VLAN 1053 1054

.6 .5.6 .5

VLAN 32 10.136.32.0/24

HSRP VIP .1

10.136.200.0/30.1 .2

Red VPN

Green VPN

2262

75

67ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

Hardware is EtherSVI, address is 000b.4594.1c00 (bia 000b.4594.1c00) Description: Firewall_Outside_Red<snip>

その結果、パケットをファイアウォール外のサブネットからファイアウォール内のサブネットに送

信しなければならないとき（またはその逆）に、ARP の解決に失敗します。ARP プロトコルのデ

バッグを可能にすることで、接続性の根本的な問題が明らかになります。

Dec 11 09:44:02.855 EST: IP ARP: creating incomplete entry for IP address: 10.136.103.6 interface Vlan1053Dec 11 09:44:02.855 EST: IP ARP: sent req src 10.136.103.3 000b.4594.1c00, dst 10.136.103.6 0000.0000.0000 Vlan1053Dec 11 09:44:02.855 EST: IP ARP req filtered src 10.136.103.3 000b.4594.1c00, dst 10.136.103.6 0000.0000.0000 it's our address

この問題を解決するには、次の設定例に示すように、SVI 内部と外部の MAC アドレスを手動で設

定することを推奨します。

S1/D1interface Vlan903 description Firewall_Inside_Red mac-address 0000.0000.0903!interface Vlan1053 description Firewall_Outside_Red mac-address 0000.0000.1053

S2/D2interface Vlan903 description Firewall_Inside_Red mac-address 0000.0001.0903!interface Vlan1053 description Firewall_Outside_Red mac-address 0000.0001.1053

特定の設定と設計の考慮事項は、ルーティング ピアリングの確立で使用しているルーティング プロト

コルによって異なり、次のセクションで説明します。

VRF およびフュージョン ルータ間での EIGRP の使用

2 ティア配置モデルでの EIGRP セクションで説明したすべての考慮事項は、シングル ティア シナリオ

でも有効です。留意すべき唯一の点は、フュージョン VRF と外部 VRF のルーティング インスタンス

が同じデバイスで有効になっており、次に示す設定につながる（S1/D1 デバイスで有効）ことです。

S1/D1router eigrp 100!address-family ipv4 Red network 10.0.0.0 no auto-summary autonomous-system 100 eigrp router-id 10.136.203.1 exit-address-family ! address-family ipv4 vrf fusion redistribute static metric 200000 100 255 1 1500 network 10.0.0.0 distribute-list Default out Vlan903 no auto-summary

68ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

autonomous-system 100 eigrp router-id 10.136.200.1 exit-address-family

SVI 内のファイアウォールの下記の例に示すように、同じ積極的な EIGRP タイマー設定は、このケー

スでも推奨されます。

S1/D1interface Vlan903 mac-address 0000.0000.0903 ip vrf forwarding Red ip address 10.136.103.6 255.255.255.0 ip hello-interval eigrp 100 1 ip hold-time eigrp 100 3

EIGRP プロトコルが、トランスペアレント モードで実行されるファイアウォールを通じて一度自動的

に許可され、2 ティア モデルのセクションで説明した ethertype ACL がインターフェイスの内部と外部

に適用されるため、次に示すように、EIGRP の隣接性がフュージョン VRF と外部 VRF 間で確立され

ます。

S1/D1S1/D1#sh ip eigrp vrf Red neighbors IP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num4 10.136.103.2 Vl1053 2 15:45:20 1 200 0 4743 10.136.103.6 Vl1053 2 15:47:41 4 200 0 222 10.136.103.5 Vl1053 2 15:47:41 1 200 0 11941 10.136.0.34 Te1/1.332 14 15:47:42 214 1284 0 5980 10.136.0.38 Te1/2.432 11 15:47:42 137 822 0 41752890S1/D1#sh ip eigrp vrf fusion neighbors IP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num3 10.136.200.2 Vl200 12 00:00:04 521 3126 0 12052 10.136.103.2 Vl903 2 15:48:04 2 200 0 4751 10.136.103.3 Vl903 2 15:50:26 1 200 0 410 10.136.103.5 Vl903 2 15:50:26 1 200 0 1204

S2/D2S2/D2#sh ip eigrp vrf Red neighbors IP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num2 10.136.103.6 Vl1053 2 15:49:00 4 200 0 311 10.136.103.3 Vl1053 2 15:49:00 3 200 0 410 10.136.103.5 Vl1053 2 15:49:00 4 200 0 12044 10.136.0.30 Te1/2.332 12 1d10h 1 200 0 417528893 10.136.0.36 Te1/1.432 12 1d10h 1 200 0 596S2/D2#sh ip eigrp vrf fusion neighbors IP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num3 10.136.200.1 Vl200 11 00:02:32 1 200 0 300 10.136.103.2 Vl903 2 15:50:32 4 200 0 4732 10.136.103.3 Vl903 2 15:52:54 170 1020 0 411 10.136.103.6 Vl903 2 15:52:54 137 822 0 31

69ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

外部 VRFが互いにピアリングされる方法と、SVI 1053 を通じてフュージョン VRF とピアリングされ

る方法に注目してください。Ten1/1 および Ten1/2 を定義している配置済みのルーテッド リンクを通じ

て、コアに配置されているデバイスにもピアリングされています。同時に、フュージョン VRF は互い

にピアリングされており、SVI 903 を通じて外部 VRF ともピアリングされています。また、SVI 200 を通じて直接ピアリングされています。このレイヤ 3 ピアリングには、特定の障害シナリオで再ルー

ティングを提供することが要求されます。

（注） 設定および設計上の推奨事項の詳細については、2 ティア配置モデルの EIGRP のセクションを参照し

てください。

VRF とフュージョン ルータ間での OSPF の使用

EIGRP の場合と同様に、OSPFでもほとんどの設定手順は 2 ティア配置のものと同じです。繰り返し

ますが、フュージョン VRF と 外部 VRF に関連づけられた OSPF プロセスは、次に示すように、同じ

デバイス内で有効となります（この設定例は S1/D1 デバイスで有効なものです）。

S1/D1router ospf 4 vrf Red router-id 10.136.103.1 log-adjacency-changes auto-cost reference-bandwidth 10000 capability vrf-lite timers throttle spf 10 100 5000 timers throttle lsa all 10 100 5000 timers lsa arrival 80 passive-interface default no passive-interface TenGigabitEthernet1/1.342 no passive-interface TenGigabitEthernet1/2.442 no passive-interface Vlan1053 network 10.136.0.0 0.0.255.255 area 136!router ospf 100 vrf fusion router-id 10.136.100.1 log-adjacency-changes auto-cost reference-bandwidth 10000 capability vrf-lite timers throttle spf 10 100 5000 timers throttle lsa all 10 100 5000 timers lsa arrival 80 passive-interface default no passive-interface Vlan903 network 10.136.0.0 0.0.255.255 area 136 default-information originate always metric 10 metric-type 1

SVI 内の例に示すように、OSPF タイマーを積極的にチューンすることが推奨されます。

interface Vlan903 mac-address 0000.0000.0903 ip vrf forwarding fusion ip address 10.136.103.6 255.255.255.0 ip ospf hello-interval 1

EIGRP プロトコルとは異なり、OSPF パケットは、EtherType ACL ではトランスペアレント モードで

実行中のファイアウォールを通過できないことに注意してください。次に示すように、OSPF がファイ

アウォールを通過できるようにするには、特定の ACE が必要です。

access-list <ACL_NAME> extended permit ospf any any

70ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

上記の設定手順の結果として、次に示すように、OSPF の隣接性がフュージョン VRF と外部 VRF 間で

確立されます。

S1/D1S1/D1 #sh ip ospf 4 neighbor Neighbor ID Pri State Dead Time Address Interface10.136.100.1 1 FULL/DROTHER 00:00:03 10.136.104.6 Vlan105410.136.100.2 1 FULL/DROTHER 00:00:03 10.136.104.5 Vlan105410.136.104.2 1 FULL/DR 00:00:03 10.136.104.2 Vlan105410.136.4.2 1 FULL/BDR 00:00:38 10.136.0.48 TenGigabitEthernet1/2.44210.136.4.1 1 FULL/BDR 00:00:38 10.136.0.44 TenGigabitEthernet1/1.342S1/D1 #sh ip ospf 100 neighbor

Neighbor ID Pri State Dead Time Address Interface10.136.100.2 1 FULL/DR 00:00:03 10.136.200.2 Vlan20010.136.100.2 1 2WAY/DROTHER 00:00:03 10.136.104.5 Vlan90410.136.104.1 1 FULL/BDR 00:00:03 10.136.104.3 Vlan90410.136.104.2 1 FULL/DR 00:00:03 10.136.104.2 Vlan904

S2/D2S2/D2 #sh ip ospf 4 neighbor Neighbor ID Pri State Dead Time Address Interface10.136.100.1 1 FULL/DROTHER 00:00:03 10.136.104.6 Vlan105410.136.100.2 1 FULL/DROTHER 00:00:03 10.136.104.5 Vlan105410.136.104.1 1 FULL/BDR 00:00:03 10.136.104.3 Vlan105410.136.4.2 1 FULL/DR 00:00:36 10.136.0.40 TenGigabitEthernet1/2.34210.136.4.1 1 FULL/DR 00:00:36 10.136.0.46 TenGigabitEthernet1/1.442 S2/D2 #sh ip ospf 100 neighbor Neighbor ID Pri State Dead Time Address Interface10.136.100.1 1 FULL/BDR 00:00:03 10.136.200.1 Vlan20010.136.100.1 1 2WAY/DROTHER 00:00:03 10.136.104.6 Vlan90410.136.104.1 1 FULL/BDR 00:00:03 10.136.104.3 Vlan90410.136.104.2 1 FULL/DR 00:00:03 10.136.104.2 Vlan904

外部 VRFが互いにピアリングされる方法と、SVI 1053 を通じてフュージョン VRF とピアリングされ

る方法に注目してください。上記の例にある Ten1/1 および Ten1/2 のサブインターフェイスを通じて、

コアに配置されているデバイスにもピアリングされています。

フュージョン VRF は互いにピアリングされており、SVI 903 を通じて外部 VRF ともピアリングされて

います。SVI 200 を通じても互いにピアリングされています。繰り返しますが、このレイヤ 3 ピアリン

グは、特定の障害復旧シナリオのもとで必要となります。

（注） 設定および設計上の推奨事項の詳細については、2 ティア配置モデルの OSPF のセクションを参照して

ください。

VRF およびフュージョン ルータ間での eBGP の使用

フュージョン ルータ、ファイアウォール、および VRF をシングル ボックスに集約することで、eBGP を利用して、ファイアウォール コンテキスト全体でルーティング ピアリングを確立するという興味深

い課題がもたらされます。

eBGP をシングル ボックス シナリオで機能させるには、次の 2 つの具体的な機能が必要となります。

• VRF アドレス ファミリごとに個別の BGP ルータ ID を提供する。

71ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

• 同じデバイスで個別の BGP ルータ プロセスを提供して、eBGP セッションを確立する。

（注） デフォルトでは、Cisco IOS は、同じデバイスで複数の BGP プロセスを作成できません。

ソフトウェア リリース 12.2(33)SXH を新たに搭載した Catalyst 6500 プラットフォームの新機能では、

上記の両方の要件が提供されます。eBGP の隣接性をファイアウォール全体で確立するのに必要な設定

を、次に示します。

S1/D1router bgp 100 timers bgp 2 10 ! address-family ipv4 vrf Red neighbor 10.136.103.5 remote-as 101 neighbor 10.136.103.5 local-as 200 no-prepend replace-as neighbor 10.136.103.5 activate neighbor 10.136.103.6 remote-as 101 neighbor 10.136.103.6 local-as 200 no-prepend replace-as neighbor 10.136.103.6 activate maximum-paths 2 no synchronization bgp router-id 10.136.200.1 exit-address-family!address-family ipv4 vrf fusion neighbor 10.136.103.2 remote-as 200 neighbor 10.136.103.2 local-as 101 no-prepend replace-as neighbor 10.136.103.2 activate neighbor 10.136.103.2 default-originate route-map default_only neighbor 10.136.103.2 route-map default_only out neighbor 10.136.103.3 remote-as 200 neighbor 10.136.103.3 local-as 101 no-prepend replace-as neighbor 10.136.103.3 activate neighbor 10.136.103.3 default-originate route-map default_only neighbor 10.136.103.3 route-map default_only out neighbor 10.136.103.5 remote-as 100 neighbor 10.136.103.5 activate maximum-paths 2 no synchronization bgp router-id 10.136.100.1 exit-address-family

S2/D2router bgp 100 timers bgp 2 10 ! address-family ipv4 vrf Red neighbor 10.136.103.5 remote-as 101 neighbor 10.136.103.5 local-as 200 no-prepend replace-as neighbor 10.136.103.5 activate neighbor 10.136.103.6 remote-as 101 neighbor 10.136.103.6 local-as 200 no-prepend replace-as neighbor 10.136.103.6 activate maximum-paths 2 no synchronization bgp router-id 10.136.200.2 exit-address-family ! address-family ipv4 vrf fusion neighbor 10.136.103.2 remote-as 200

72ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

neighbor 10.136.103.2 local-as 101 no-prepend replace-as neighbor 10.136.103.2 activate neighbor 10.136.103.2 default-originate route-map default_only neighbor 10.136.103.2 route-map default_only out neighbor 10.136.103.3 remote-as 200 neighbor 10.136.103.3 local-as 101 no-prepend replace-as neighbor 10.136.103.3 activate neighbor 10.136.103.3 default-originate route-map default_only neighbor 10.136.103.3 route-map default_only out neighbor 10.136.103.6 remote-as 100 neighbor 10.136.103.6 activate maximum-paths 2 no synchronization bgp router-id 10.136.100.2 exit-address-family

上記の設定例（ここでも有効な 2 ティア モデルの eBGP セクションで行ったものに追加したもの）に

関しては、いくつかの重要な考慮事項があります。

• シングル BGP プロセス（ルータ bgp 100）が設定されているにもかかわらず、その目的はフュー

ジョン VRF と Red VRF 間で eBGP セッションを確立することにあるため、BGP ネイバーは、2 つの異なる AS 番号（101 と 200）を使用して設定されています。これを機能させるためには、

BGP がデュアル AS 設定をサポートしている必要があります。これは、local-as コマンドを使用す

ることで可能になります。その結果、Red VRF の BGP インスタンスが、リモート AS 101 のシス

テムを使用して eBGP ネイバーを確立しようとしますが、ローカル AS 200 のネイバーシップ要求

を受け入れます。フュージョン VRF の BGP インスタンスでは、その逆もまた有効です。

（注） BGP のデュアル AS 設定のサポートの詳細については、次の URL を参照してください。http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html

• 個別の BGP ルータ ID が、フュージョン VRF と Red VRF アドレス ファミリで設定されます。

• eBGP セッションが、図 35 に示す設計方針に従って、フュージョン VRF と外部 VRF 間でフル

メッシュ方式で確立されます。

• フュージョン VRF 間でさらに iBGP ピアリングが確立されます。これは、フュージョン ルータが

共有サービス エリアとの直接接続が切れてしまうような障害シナリオにおいて、再ルーティング

機能を提供するのに必要です。この iBGP ピアリングを確立するために指定された AS 番号が、

ボックス（AS 100）で設定された 全体的な BGP プロセスと同じものであることに注目してくださ

い。

次に示すように、eBGP ピアリング セッションが正常に確立される前に、これらのパケットがファイ

アウォールを通じて許可される必要があります。

access-list <ACL_NAME> extended permit tcp any any eq bgp

上記の設定手順の結果として、次に示すように、フュージョン VRF と外部 VRF 間で eBGP セッショ

ンが確立されます。

S1/D1S1/D1#sh ip bgp vpnv4 vrf Red summary BGP router identifier 10.136.200.1, local AS number 100<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.103.5 4 101 29782 29805 3441362 0 0 16:56:28 110.136.103.6 4 101 29780 29805 3441362 0 0 16:56:29 1S1/D1#sh ip bgp vpnv4 vrf fusion summaryBGP router identifier 10.136.100.1, local AS number 100<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

73ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

10.136.103.2 4 200 29906 29891 3453884 0 0 17:00:16 3910.136.103.3 4 200 29916 29891 3453884 0 0 17:00:17 3910.136.103.5 4 100 1451545 1351372 3453884 0 0 17:00:11 103

S2/D2S2/D2#sh ip bgp vpnv4 vrf Red summaryBGP router identifier 10.136.200.2, local AS number 100<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.103.5 4 101 40920 41092 3533870 0 0 17:16:42 110.136.103.6 4 101 40292 40505 3533870 0 0 17:09:24 1S2/D2#sh ip bgp vpnv4 vrf fusion summaryBGP router identifier 10.136.100.2, local AS number 100<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.103.2 4 200 105398 105151 3538990 0 0 17:18:15 3910.136.103.3 4 200 194634 194165 3538990 0 0 17:10:57 3910.136.103.6 4 100 8935809 9021284 3538990 0 0 17:10:53 104

上記で説明したように、リモート AS 101 での場合と同様に、外部 VRF がフュージョン VRF とピアリ

ングされています。同時に、AS 200 での場合と同様に、フュージョン VRF は外部 VRF ともピアリン

グされています。フュージョン VRF 間の iBGP ピアリングが、代わりに AS 100（「真の」 BGP AS）を

使用して実行されます。

（注） 設定および設計上の推奨事項の詳細については、2 ティア配置モデルの eBGP のセクションを参照して

ください。

ルーテッド モードで配置されたファイアウォール コンテキスト

デュアル ティア配置モデルで説明したものと同様に、ファイアウォール コンテキストをルーテッド モードで配置する場合には、図 37 に示したように、eBGP が推奨されます。

74ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 37 ルーテッド モードでのファイアウォール コンテキストとのルーティング ピアリング

シングル ティア シナリオでの対応するお勧めの配置モデルを図 38 に示します。

RedVPN

GreenVPN

YellowVPN

L3L3 L3

eBGP

2262

65

75ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

図 38 ルーテッド モードでのファイアウォール コンテキストの例

図 38 から次の考慮事項が導かれます。

• 各ファイアウォール コンテキストは、ネットワーク内でルーテッド ホップになります。これは、

VLAN の内部および外部のファイアウォールが異なる 2 つの IP サブネットに属するようになるこ

とを意味します。

• HSRP は、 適な First Hop Redundancy Protocol で、次のインターフェイス用に仮想ゲートウェ

イ機能を提供するのに利用されます。

– 共有サービス サブネット（VLAN 32）：これは、フュージョン デバイスに直接接続されてい

るサブネット内に共有サービスが配置されていることが前提です。

– サブネット内のファイアウォール（Red VPN には VLAN 903、Green VPN には VLAN 904）。

– サブネット外のファイアウォール（Red VPN には VLAN 1053、Green VPN には VLAN 1054）。

• フュージョン VRF はルーテッド リンクに接続されたままです。これは、特定の障害条件のもとで

トラフィックの再ルーティングに使用されるレイヤ 3 パスを提供するためのものです。

.3

.3

.2

.2

S1/D1 S2/D2

VLAN 903 10.136.113.0/24 VLAN 904 10.136.114.0/24

VLAN 1054 10.136.104.0/24VLAN 1053 10.136.103.0/24

HSRP VIP .1VLAN 903 904

HSRP VIP .1VLAN 1053 1054

.3 .2.3 .2

VLAN 32 10.136.32.0/24

HSRP VIP .1

10.136.200.0/30.1 .2

Red VPN

Green VPN

.5

.5

.5

.5

.4

.4

.4

.4

2262

76

76ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

適なルーティング プロトコルが通過できるように各ファイアウォール コンテキスト上のポリシーが

適切に配置されている場合には（eBGP に必要な設定は、このマニュアルのプロトコル特有のセクショ

ンで後ほど説明されます）、図 35 に示すように、各 VRF が両方の フュージョン VRF とピアリングし

ます。

次のセクションでは、eBGP の配置に関する特定の設計と設定上の考慮事項について説明し、これまで

に説明してきたすべての障害シナリオのコンバージェンス結果を一覧します。

VRF およびフュージョン ルータ間での eBGP の使用

トランスペアレント モードのファイアウォール配置ですでに説明した、シングル ティアの eBGP 配置

の同じ課題が、ここでも現れます。VRF ごとの個別 BGP ルータの使用と、BGP によるデュアル AS 設定のサポートに基づく同じソリューションが、ルーテッド モードで機能するファイアウォールでも

利用できます。対応する設定が、下記で強調表示されています。

S1/D1router bgp 100 timers bgp 2 10 ! address-family ipv4 vrf Red neighbor 10.136.103.2 remote-as 101 neighbor 10.136.103.2 local-as 200 no-prepend replace-as neighbor 10.136.103.2 ebgp-multihop 2 neighbor 10.136.103.2 activate neighbor 10.136.103.3 remote-as 101 neighbor 10.136.103.3 local-as 200 no-prepend replace-as neighbor 10.136.103.3 ebgp-multihop 2 neighbor 10.136.103.3 activate maximum-paths 2 no synchronization bgp router-id 10.136.206.1 exit-address-family!address-family ipv4 vrf fusion neighbor 10.136.103.2 remote-as 100 neighbor 10.136.103.2 activate neighbor 10.136.113.2 remote-as 200 neighbor 10.136.113.2 local-as 101 no-prepend replace-as neighbor 10.136.113.2 ebgp-multihop 2 neighbor 10.136.113.2 activate neighbor 10.136.113.2 default-originate route-map default_only neighbor 10.136.113.2 route-map default_only out neighbor 10.136.113.3 remote-as 200 neighbor 10.136.113.3 local-as 101 no-prepend replace-as neighbor 10.136.113.3 ebgp-multihop 2 neighbor 10.136.113.3 activate neighbor 10.136.113.3 default-originate route-map default_only neighbor 10.136.113.3 route-map default_only out maximum-paths 2 no synchronization bgp router-id 10.136.100.1 exit-address-family

S2/D2router bgp 100 timers bgp 2 10 ! address-family ipv4 vrf Red neighbor 10.136.103.2 remote-as 101 neighbor 10.136.103.2 local-as 200 no-prepend replace-as neighbor 10.136.103.2 ebgp-multihop 2

77ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

保護された共有サービスの導入

neighbor 10.136.103.2 activate neighbor 10.136.103.3 remote-as 101 neighbor 10.136.103.3 local-as 200 no-prepend replace-as neighbor 10.136.103.3 ebgp-multihop 2 neighbor 10.136.103.3 activate maximum-paths 2 no synchronization bgp router-id 10.136.200.2 exit-address-family ! address-family ipv4 vrf fusion neighbor 10.136.103.3 remote-as 100 neighbor 10.136.103.3 activate neighbor 10.136.113.2 remote-as 200 neighbor 10.136.113.2 local-as 101 no-prepend replace-as neighbor 10.136.113.2 ebgp-multihop 2 neighbor 10.136.113.2 activate neighbor 10.136.113.2 default-originate route-map default_only neighbor 10.136.113.2 route-map default_only out neighbor 10.136.113.3 remote-as 200 neighbor 10.136.113.3 local-as 101 no-prepend replace-as neighbor 10.136.113.3 ebgp-multihop 2 neighbor 10.136.113.3 activate neighbor 10.136.113.3 default-originate route-map default_only neighbor 10.136.113.3 route-map default_only out maximum-paths 2 no synchronization bgp router-id 10.136.100.2 exit-address-family

上記の設定の 終結果は、トランスペアレント モードでの配置のケースと同様に、eBGP ピアリング

の確立となります。

S1/D1S1/D1#sh ip bgp vpnv4 vrf Red summary BGP router identifier 10.136.200.1, local AS number 100<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.106.2 4 101 33549 1195471 3879287 0 0 03:32:54 110.136.106.3 4 101 33559 1195843 3879287 0 0 03:33:19 1S1/D1#sh ip bgp vpnv4 vrf fusion summaryBGP router identifier 10.136.100.1, local AS number 100<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.106.2 4 100 1632771 1520788 3886064 0 0 19:08:03 10410.136.116.2 4 200 1205825 33618 3886095 0 0 03:35:10 3910.136.116.3 4 200 1197863 33624 3886095 0 0 03:35:24 39

S2/D2S2/D2#sh ip bgp vpnv4 vrf Red summaryBGP router identifier 10.136.200.2, local AS number 100<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.106.2 4 101 37514 1217035 3943814 0 0 03:34:45 110.136.106.3 4 101 37227 1213227 3943814 0 0 03:35:55 1S2/D2#sh ip bgp vpnv4 vrf fusion summaryBGP router identifier 10.136.100.2, local AS number 100<snip>Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.136.106.3 4 100 4255452 4368163 3945041 0 0 19:09:09 10410.136.116.2 4 200 5509274 186755 3945069 0 0 03:35:07 3810.136.116.3 4 200 5239082 174719 3945069 0 0 03:36:06 38

78ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワークにおけるサイト冗長性の計画

（注） 設定および設計上の推奨事項の詳細については、2 ティア配置モデルの eBGP のセクションを参照して

ください。

シングル ティアの実装：概要と設計の推奨事項

説明したシングル ティア配置モデルは、すべての機能（フュージョン ルーティング、ファイアウォー

ル サービス、VRF 終了）を単独の物理デバイスで維持する小規模の配置で推奨されるもので、運用面

での実現性が保たれています。2 ティア シナリオの場合と同様に、トランスペアレント モードまたは

ルーテッド モードで機能する両方のファイアウォール コンテキストをサポートすることが可能で、次

で簡単に説明するように、2 つのシナリオで同じルーティング プロトコルを使用できます。

• トランスペアレント モードのファイアウォール：EIGRP、OSPF、または eBGP

• ルーテッド モードのファイアウォール：eBGP

配置の観点からは、このシングル ボックス実装に固有の 2 つのポイントがあります。

• サブネット内とサブネット外のファイアウォールで定義されている VLAN インターフェイスの MAC アドレスは、手動で設定する必要があります。これは、デフォルトで同じ MAC アドレスを

定義されているすべての SVI に割り当てる、特定の Catalyst の動作に対応するために必要なもの

です。

• サービスのルーティング エッジとして eBGP を使用する場合は、2 つの追加機能を設定して、同じ

物理デバイスで定義されている VRF 間で eBGP ピアリングが正常に確立される、つまり、VRF ごとの固有の BGP ルート ID が定義され、BGP によるデュアル AS 設定がサポートされるようにす

ることが必須となります。どちらの機能も、IOS バージョン 12.2(33)SXH 以降を実行する Catalyst 6500 プラットフォームで使用できます。

コンバージェンスの観点からは、シングル ティア配置で実現される結果は、2 ティア モデルのものと

同様となります。さまざまな障害シナリオ（これらの障害シナリオのサブネットだけが、シングル ティア モデルに適用されます）のもとでの結果の概要については、表 1 を参照してください。

仮想ネットワークにおけるサイト冗長性の計画共有サービスに対して保護されたアクセスを提供するための、サービス エッジに関する議論は、シン

グル サイト配置を対象としたものが中心でした。この場合は、冗長ディストリビューション スイッチ

とサービス スイッチ、冗長ファイバ接続、冗長ファイアウォール モジュールなどを展開することで、

サイト内の冗長性が提供されます。

このセクションでは、主にサイト間の冗長性を提供する場合の設計上の考慮事項について説明します。

このシナリオでは、サービス エッジのファイアウォールを通過するすべてのトラフィック ストリーム

が対称的なルーティング パスに従うようにする、すなわち、エンドポイントとの間でやり取りされる

トラフィックが同じファイアウォールを通過して、ファイアウォール インスペクション ポリシーをパ

スするための配慮が必要となることが明確になります。

デフォルトの冗長サイト設定

図 39 に、大規模なキャンパス ネットワークを示します。キャンパス全体に数多くのビルディングが存

在していますが、この例のビルディング -1 とビルディング -9 は、サービス エッジ機能を提供していま

す。それぞれの共有サービス サイトは、シングル ルータと、各クライアント VPN のファイアウォー

ルを示していますが、共有サービス設計は、このマニュアルの前のセクションで説明したサイト内冗長

79ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワークにおけるサイト冗長性の計画

性のガイダンスに従う必要があります。これは、Red VPN と Green VPN が同じルータとファイア

ウォール上の仮想インスタンスとなり、各サイトに冗長ルータとファイアウォールを配置できることを

意味します。

共有サービス VPN は、専用の接続または同じキャンパス インフラストラクチャで仮想化された接続を

経由して、ビルディング -1（サイト 1）とビルディング -9（サイト 2）の間に配置できます。可能なオ

プションとして、グローバル テーブル（すなわちデフォルト VPN）を使用して、共有サービス拡張機

能を提供することもできます。

図 39 冗長サービス エッジの配置

フュージョン ルータとサービス エッジ ルータ間の実際のルーティング方法はここでは説明しません

が、次の状況が合理的な前提条件として考えられます。

• 共有サービス VPN の両方のフュージョン ルータは、Red VPN と Green VPN に対してルートをア

ドバタイズします。すでに説明したように、通常は定義された外部 VRF にデフォルト ルートをア

ドバタイズするように、フュージョン ルータを設定します。これらのデフォルト ルートは、定義

された VPN に属する他のすべてのキャンパス デバイスに対してアドバタイズされます。

• 外部 VRF は、ルーティング情報をフュージョン ルータにアドバタイズし、リモート キャンパス サブネットに対する接続を提供します。

共有サービス サーバは、通常はフュージョン ルータに直接接続されているサブネット上に配置されま

す。フュージョン ルータはデフォルト ゲートウェイとなり、次の状況が合理的に予想されます。

VPN

-1

-1

-9

-9

Green Red

2262

77

80ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワークにおけるサイト冗長性の計画

• キャンパス コアの VPN を宛先とするトラフィックを送信するビルディング -1 の共有サーバは、多

くの場合、ビルディング -1 のサービス エッジに配置されているファイアウォール コンテキストを

経由して、トラフィックを送信します。

• キャンパス コアの VPN を宛先とするトラフィックを送信するビルディング -9 の共有サーバは、多

くの場合、ビルディング -9 のサービス エッジに配置されているファイアウォール コンテキストを

経由して、トラフィックを送信します。

それぞれのサービス エッジ ルータからのデフォルト ルートは、ネットワークを通じて伝播するた

め、キャンパス コアのすべてのルータは、共有サービス VPN への 小負荷のルートを知ることが

できます。

• トラフィックを共有サービス VPN に送信するキャンパス コアのクライアントまたは他のクライア

ント VPN は、クライアント ローカル ルータに見られるように、 小負荷のデフォルト ルート メトリックを使用して、サービス エッジ ルータにルートされます。

非対称ルーティング パスの課題

図 40 は、クライアントと共有サービス間のトラフィックが、異なるパスを取る場合の問題を示してい

ます。

図 40 非対称ルーティングパス

VPN

-1

-1

-9

-9

Green Red

1

5

4

3

2

2262

78

81ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワークにおけるサイト冗長性の計画

この例は、クライアントからのトラフィックが、クライアントへのトラフィックとは異なるサービス エッジにルートされた場合に、キャンパス コアのクライアントが、共有サービス VPN のサーバを使用

して TCP セッションを確立できないことを示しています。これが起こるケースとして数多くのシナリ

オが考えられますが、その具体例の 1 つを「仮想ネットワーク インフラストラクチャにおける音声テ

クノロジー」 に示します。

1. この例のクライアントからのトラフィックは、キャンパス コアの一部で、ビルディング -1 のサー

ビス エッジからのデフォルト ルートは、ビルディング -9 からのデフォルト ルートよりも低いメト

リックを持っています。クライアントからのトラフィックは、ビルディング -1 のサービス エッジ

へのデフォルト ルートに従います。

2. ファイアウォールはトラフィックのインスペクションを行い、TCP ハンドシェークの一部として

クライアントから発信された SYN パケットを認識します。

3. ビルディング -1 のフュージョン ルータは、共有サービス VPN からビルディング -9 の宛先サーバ

へのトラフィックのルーティングを行います。

4. ビルディング -9 のサーバは、ビルディング -9 のローカル サービス エッジを経由したクライアント VPN へのトラフィックのルーティングを行います。

5. ビルディング -9 のファイアウォールはクライアントからの TCP SYN を認識せず、サーバから発信

された SYN-ACK メッセージを破棄して、接続が確立されないようにします。

対称ルーティング パスの確保

図 41 に、クライアントと共有サービス エリアの間の非対称ルーティングを防ぐためのソリューション

を示します。この設計の目的は、キャンパス コアのクライアントと共有サービス VPN 間のすべてのパ

ケットが、常に同じ物理サービス エッジ サイトを経由してルーティングされるようにすることです。

これにより、ファイアウォール インスペクションが双方向トラフィックを確認します。

この設計では、トラフィックのロード バランシングが行われ、1 つのサービス エッジ サイトが半分の

ルーティングを行い、他のサイトが残りの半分のルーティングを行います。代替方法として、すべての VPN を 1 つのサイトにルーティングして、他のサイトをバックアップとして使用する方法もあります。

どちらのアプローチも有効ですが、このドキュメントでは、ロード バランス設計に重点を置きます。

図 41 では、ルーティング プロトコルが次のようにチューニングされています。

• 共有サービス VPN は、ビルディング -1 を経由した Green VPN へのベストのルートと、ビルディ

ング -2 を経由した Red VPN へのベストのルートを常に探っています。

• キャンパス コアは、ビルディング -1 のサービス エッジを経由する Green VPN へのデフォルト ルートと、ビルディング -2 のサービス エッジを経由するデフォルト ルートを常に探っています。

82ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワークにおけるサイト冗長性の計画

図 41 対称ルーティング パスの確保

トラフィック フローに対するこのチューニングの結果は、次のようになります。

• Green クライアントがトラフィックをビルディング -9 のサーバに送信します。このトラフィック

のデフォルト ルートが、トラフィックをビルディング -1 のサービス エッジへと誘導します。そこ

から、トラフィックが共有サービス VPN へ、そして共有サービス VPN 内からビルディング -9 のサーバへとルートされます。共有サービス VPN のルータは、ビルディング -1 を経由する Green VPN への 小負荷のルートを持っており、クライアントへのすべてのトラフィックが同じパスを

経由します。

• ファイアウォールは、双方向トラフィックのインスペクションを行い、フル TCP ハンドシェーク

と、クライアントとサーバ間ですべてのパケットが許可されるのを確認できます。

対称ルーティング フェールオーバー

サイト内冗長性を配置することで、サイト内のリンクまたはデバイスの障害からの復旧が可能となりま

す。このセクションでは、サイト全体の障害の際に障害回復の機能を提供するサイト内冗長性について

説明します。

この例では、図 42 にあるように、ルーティング プロトコルが、ビルディング -1 のサービス エッジで

障害が発生した場合にネットワークが生き残るようにする方法を確認できます。

VPN

-1

-1

Green

Red

-9

-9

Red

Green

2262

79

83ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワークにおけるサイト冗長性の計画

図 42 サービス エッジ サイト障害

• クライアントは、ビルディング -1 との間のチューニングされたルーティング パスに従い、ビル

ディング -9 のルータへのルートを確保します。ビルディング -1 へのネットワーク接続は失われて

います。

• ルーティング プロトコルは、ビルディング -9 の共有サービスで再収束します。

– ビルディング -1 のフュージョン ルータが、Green VPN へのルートのアドバタイズを停止し

て、代わりにビルディング -9 のフュージョン ルータからのルートが使用されます。

– ビルディング -1 のサービス エッジルータが、デフォルト ルートのアドバタイズを停止して、

代わりにビルディング -9 のサービス エッジ ルータによってアドバタイズされるデフォルト ルートが使用されます。

• クライアントとの間のルートはビルディング -9 のサービス エッジを経由するようになり、ファイ

アウォールがトラフィックのインスペクションを行い、許可できるようになります。

対称ルーティング クライアントのトラフィック フロー

図 43 は、対称トラフィック パスを確保するようチューニングされたルーティング機能を持つ、冗長

ネットワークの形成が可能なトラフィック パターンを示します。この例では、Green VPN と Red VPN があります。

VPN

-1

-1

Green

Red

-9

-9

Red

Green

1

3

2

2262

80

84ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワークにおけるサイト冗長性の計画

図 43 対称トラフィック フロー

• 同じ VPN の一部であるキャンパス コアのクライアント間のトラフィックは、VPN 内ルーティン

グの変更の影響を受けません。

• 異なる VPN のクライアント間のトラフィックは、Green VPN との間のすべてのトラフィックがサ

イト -1 を経由し、Red VPN との間のすべてのトラフィックがサイト -2 を経由するようチューニン

グされています。

図 43 では、サイト -1 の Green ファイアウォールが Green VPN との間のすべてのトラフィックのイン

スペクションを行い、サイト -2 の Red ファイアウォールが Green VPN との間のすべてのトラフィック

のインスペクションを行います。

仮想ネットワークにおけるサイト冗長性の設定 ドキュメントのこのセクションでは、ルーティング プロトコルのチューニングの設定ガイドとして、

指定したキャンパス コア VPN との間のトラフィックが、常に同じサービス エッジ サイトを使用する

（対称ルーティング パスを確保する）方法を説明します。

使用する主な特定の設定は、次の 2 つの要素によって異なります。

• 運用上のファイアウォール コンテキスト モード：ファイアウォールをトランスペアレント（また

はレイヤ 2 ブリッジング）モードまたはルーテッド （レイヤ 3）モードで配置可能。

VPN

-1

-1

Green

Red

-9

-9

Red

Green

1

2262

81

85ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワークにおけるサイト冗長性の計画

• 各 VRF とフュージョン ルータ間でルートを交換するのに使用するルーティング プロトコル：運用

上のファイアウォール モードによって異なる。トランスペアレント モードのファイアウォールで

はすべてのオプション（EIGRP、OSPF、および eBGP）で使用できますが、ルーテッド モードの

ファイアウォールでは、eBGP が一般的に推奨できるアプローチとなります。

好ましい動作を実現する実装のための高度な設計原則を図 43 に示します。上記の例では、ビルディン

グ -1 のフュージョン ルータで次のことが必要となります。

• Red サブネットの共有 VPN に高度なメトリックを挿入する。

• 高度なメトリックを挿入したルートを Red ディストリビューション VRF（通常はデフォルト ルー

トだけがフュージョン ルータからディストリビューション VRF に送信される）にアドバタイズす

る。

ビルディング -9 のフュージョン ルータは、Green VRF で同じ操作を実行します。

次のシナリオで、EIGRP をフュージョン ルータとディストリビューション VRF 間のルーティング プロトコルとして利用する、特定の配置で有効なルーティング チューニングの例を示します。この具体

例では、次の 2 つの前提も必要です。

• ファイアウォールがトランスペアレント モードで展開されている。

• EIGRP が、共有 VPN 内または各特定 VPN のキャンパス全体で使用されるルーティング プロトコ

ルである（すなわち、VRF-Lite End-to-End 設計）。

EIGRP：ルート チューニングでのオフセットリストの使用

ファイアウォールがトランスペアレント モードの場合は、サービス エッジ ルータとフュージョン ルー

タ間のトラフィックをブリッジします。これは、フュージョン ルータとサービス エッジ ルータのルー

ティング プロトコルが、隣接関係を確立し、ルーティングの更新内容を交換できることを意味します。

EIGRP を、フュージョン ルータと VRF 間のルートの交換プロトコルとして使用するシナリオを図 44 に示します。

86ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワークにおけるサイト冗長性の計画

図 44 EIGRP オフセットリストの使用

次のセクションでは、フュージョン ルーティング インスタンス上のルータ インターフェイスの 1 つで

オフセットを設定します。すべてのインターフェイスにオフセットを追加して、フュージョン ルー

ティング インターフェイスでの優先 VPN を減らす必要があります。ビルディング -1 のフュージョン ルータを例として考えると、オフセットリストをサブネット内の Red ファイアウォールに対応する SVI と、共有 VPN に接続されているインターフェイスに適用することを意味します。

1. オフセットリストを設定する前のネットワーク設定は、次のようになります。

次の出力は、ネットワーク コアのルータからのルーティング テーブルの一部を示します。これか

ら、Red VPN と Green VPN に、それぞれ 2 つの等負荷のデフォルト ルートが存在することがわ

かります。これらのデフォルト ルートは、それぞれ異なるサイトのサービス エッジ ルータを指し

ています。

c1#sh ip route vrf RedRouting Table: Red<...>D*EX 0.0.0.0/0 [170/3072] via 10.1.0.7, 00:00:37, GigabitEthernet1/4.53 [170/3072] via 10.1.0.5, 00:00:37, GigabitEthernet1/3.63c1#sh ip route vrf GreenRouting Table: Green<...>D*EX 0.0.0.0/0 [170/3072] via 10.2.0.7, 00:00:37, GigabitEthernet1/4.54 [170/3072] via 10.2.0.5, 00:00:37, GigabitEthernet1/3.64

2. オフセットリストを設定します。

VPN

-1

-1

Green

Red

-9

-9

Red

Green

VPN

Red

VRF

Red

VPN

Green

VRF

Green

2262

82

87ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワークにおけるサイト冗長性の計画

変更を行う方法を示します。offset-list コマンドが、オフセットが適用されるインターフェイスの

アクセス リストに一致するネットワークのメトリックに、1000 の正のオフセットを、追加しま

す。異なるオフセットリストを以前説明した 2 つのインターフェイスに適用する方法に注意してく

ださい。この場合、デフォルト ルートは通常ディストリビューション VRF にアドバタイズされ、

そこでは、所定の各 VPN で使用可能なアドレス空間全体を共有 VPN に挿入する必要があります。

ビルディング -1 のフュージョン ルータ

ip access-list standard Defaultpermit 0.0.0.0!ip access-list standard routes_into_shared_VPNpermit 10.1.0.0 0.0.255.255!router eigrp 100!address-family ipv4 vrf fusion offset-list Default out 1000 VLAN23 offset-list routes_into_shared_VPN out 1000 vlan23

ビルディング -9 のフュージョン ルータ

ip access-list standard Defaultpermit 0.0.0.0!ip access-list standard routes_into_shared_VPNpermit 10.2.0.0 0.0.255.255!router eigrp 100!address-family ipv4 vrf fusion offset-list Default out 1000 VLAN24 offset-list routes_into_shared_VPN out 1000 vlan24

（注） 上記の例の VLAN 23 は、サブネット内（ビルディング -1）の Red ファイアウォールに関連づ

けられている SVI です。この場合、VLAN 24 はサブネット内（ビルディング -9）の Green ファイアウォールに関連づけられている SVI となります。10.1.0.0/16 は、Red VPN のキャン

パスで定義されているすべてのルートの概要です。この場合、10.2.0.0/16 は、Green VPN のキャンパスで定義されているすべてのルートの概要となります。

3. オフセットリスト設定の結果は、次のようになります。

これは、変更が行われた後のネットワーク コアのルータからのルーティング テーブルの一部です。

これで、ルーティング テーブルに、追加のオフセットが適用されたルートが表示されます。

c1#sh ip route vrf RedRouting Table: Red<...>D*EX 0.0.0.0/0* [170/3072] via 10.1.0.5, 00:03:51, GigabitEthernet1/3.63c1#sh ip route vrf GreenRouting Table: Green<...>D*EX 0.0.0.0/0* [170/3072] via 10.2.0.7, 00:03:51, GigabitEthernet1/4.54

上記で説明したように、2 つの異なる VPN のデフォルト ルートが、ビルディング -1（Green VPN）とビルディング -9（Red VPN）の、2 つの異なる方向を指しています。また、共有 VPN は同じキャンパス コアを経由して拡張されることが前提で、返されるトラフィック（特定の VPN サブネット向け）が誘導される方法もわかります。

c1#sh ip route vrf fusion Routing Table: Red

88ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

<...>D*EX 10.1.0.0/16* [170/3072] via 12.1.0.5, 00:03:51, GigabitEthernet1/3.65D*EX 10.2.0.0/16* [170/3072] via 12.1.0.7, 00:03:51, GigabitEthernet1/4.55

Red VPN（10.1.0.0/16 アドレス空間）に属するキャンパス サブネットに向かうトラフィックは、

ビルディング -9 に誘導されます。この場合、Green （10.2.0.0/16 アドレス空間）を宛先とするト

ラフィックは、ビルディング -1 に誘導されます。したがって、トラフィックの全体的な動作は、

図 43 に示すようになります。

仮想ネットワーク サイトの冗長性の概要

バーチャライゼーションは、すべての通常の冗長環境で展開できます。このドキュメントの 初に、冗

長ファイアウォール モジュール、冗長スイッチ、ファイバ接続を使用して、サービス エッジ展開にサ

イト内冗長性を提供する方法について説明しました。

冗長サービス エッジ サイト（すなわちサイト内冗長性）を使用する機能も利用できますが、すべての

トラフィック ストリームが対称トラフィック パスに従うように注意する必要があります。すなわち、

エンドポイントとの間のトラフィックが同じサービス エッジ サイトのファイアウォールを通過して、

ファイアウォール インスペクション ポリシーにパスする必要があります。

サービス エッジ ルータとフュージョン ルータで使用されるルーティング プロトコルをチューニングし

て、キャンパス コアの指定した VPN との間のトラフィックが、常に同じサービス エッジ サイトを使

用するようにする必要があります。

選択する設計は、サービス エッジ ルータ間のファイアウォールの設定方法と、フュージョン ルータと

ディストリビューション VRF 間のルートを交換するために選択したルーティング プロトコルによって

異なります。運用のファイアウォール モードと対応する推奨ルーティング プロトコルは、次のとおり

です。

• トランスペアレント ファイアウォール モード：EIGRP、OSPF、eBGP

• ルーテッド ファイアウォール モード：eBGP

EIGRP 展開の特定のケースでは、オフセットリストを使用して、特定の VPN と共有サービス エリア

（または異なる VPN）との間のトラフィックのルーティングに影響を与える単純な方法を見てきまし

た。

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

ビジネスの分野では、ネットワーク バーチャライゼーションを使用して、組織のさまざまなエリアを

互いに分類します。このセクションでは、ネットワーク バーチャライゼーションが展開された後でも、

組織のすべてのエリアがキャンパス ネットワーク全体で通信とコラボレーションを行う状態を維持す

るためのガイダンスを提供します。

このドキュメントの現行バージョンの前の段階では、統合された通信アプリケーションが仮想ネット

ワーク インフラストラクチャでテストされておらず、グローバル テーブルで統合された通信アプリ

ケーションを展開することが推奨されていました。このドキュメントの現行バージョンでは、UC がグ

ローバル テーブル外で動作できるようになり、音声、ビデオ、コラボレーションなどの統合された通

信が、組織のさまざまな仮想セグメント（または VPN）間と仮想セグメント内で発生するアーキテク

チャが提供されています。

89ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

（注） このドキュメントの現行バージョンの統合された通信セクションでは、キャンパス展開を中心に扱いま

す。ブランチ展開は、WAN リンクからサービス エッジへの好ましくないVPN VoIP 間トラフィックと

なるため、より困難な課題となります。将来のバージョンでは、ブランチ展開による課題を扱う予定で

す。

仮想化された統合された通信トラフィック フローの概要

このセクションの目的は、仮想キャンパス ネットワークに完全に統合された、統合された通信のエン

ドポイントを実現するネットワーク設計を提供することです。過去のガイダンスでは、統合された通信

のエンドポイントとインフラストラクチャをすべてグローバル テーブルに置いていました。この章で

は、統合された通信のエンドポイントを複数の VPN に置いて、互いにセキュアな通信を行うことが可

能なネットワーク設計の方法を説明します。

この設計では、Cisco Unified Communications Manager のような統合された通信のサーバが、定義さ

れているすべての VPN の中央リソースとして展開されます。「保護された共有サービスの導入」です

でに説明したように、ファイアウォールを各 VPN のフロントエンドで使用して、厳格なセキュリティ ポリシーによる共有エリアへのアクセス制御を行うことが可能です。このセクションの図では、個別の

ファイアウォールが示されていますが、それらは単一の物理ファイアウォール内の仮想インスタンス

（コンテキスト）として展開できます。

次に説明するのは、この保護されたサービス エッジ モデルを使用して、統合された通信のアプリケー

ションを仮想ネットワーク インフラストラクチャに統合する場合の初期設計の前提条件です。

• ファイアウォール外部のインターフェイスは、特定のフィルタを使用して設定され、IP テレフォ

ニー エンドポイント VPN からの統合された通信が、共有サービスのサーバに到達できるようにし

ます。

• ファイアウォール内部のインターフェイスは、共有サービス VPN からのすべてのトラフィックが IP テレフォニー エンドポイント VPN に到達できるようにします。

• ファイアウォール インターフェイス フィルタによって許可されたトラフィックは、プロトコル アノマリー検出、アプリケーション ステートおよびプロトコル ステート トラッキングなどのファイ

アウォール テクノロジーを使用して、インスペクションが行われます。

このセクションで提案する設計の基礎となる主要な技術的機能は、トラフィックのインスペクションを

行うCisco ファイアウォールです。これにより、ファイアウォールがコール シグナリング プロトコル

のインスペクションを行い、ファイアウォール ピンホールを動的に開いて、2 つの異なる VPN 間のト

ラフィックを許可することが可能になります。ファイアウォールは、コールが終了すると、ピンホール

を動的に閉じます。この機能は、ファイアウォール設定を簡素化して、VPN 内音声ストリームを許可

するのに必要な静的ホールの数を減らすため、重要なものとなります。

提案ソリューションの性格を考えると（ファイアウォール インスペクションに基づいて）、冗長サービ

ス エッジ展開で非対称ルーティングを回避するために必要だったこれまでの考慮事項は、ここでも具

体的に関連してきます。これは、特定の VPN に属するエンドポイントのシグナリングとメディア トラ

フィックが、常に同じファイアウォール コンテキスト（同じサービス エッジ物理ロケーションに存在

する）を通過するようにするために、提案ソリューションで重要となるポイントです。この動作を実現

する方法の詳細については、「仮想ネットワークにおけるサイト冗長性の計画」を参照してください。

すでに説明したように、フュージョン ルータは、サービス エッジ設計で、共有サービス VPN と他の VPN 間の IP ルート接続、または VPN 間のルート トラフィック接続を提供するのに使用されます。音

声統合ソリューションの特定のコンテキストでは、フュージョン ルータは次の動作を実行します。

• フュージョン ルータは、IP テレフォニー エンドポイント VPN からのすべてのルートを、共有

サービス VPN に再配信します。

90ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

• フュージョン ルータは、単一のデフォルト ルートを IP テレフォニー エンドポイント VPN にアド

バタイズします。これらの VPN は、自身の VPN 内のサブネットのルートだけを持っており、デ

フォルト ルートからフュージョン ルータへのルートを使用して、共有サービス VPN または他の VPN の IP エンドポイントに到達します。

図 45 音声統合のファイアウォール インスペクション

図 45 は、音声 VPN の IP 電話と、データ VPN の PC ベースのソフトフォンとの間の音声コールの、ト

ラフィック フローとインスペクション ポイントを示します。

1. Red IP 電話が Green IP 電話の番号をダイアルすると、シグナリング メッセージが Red IP 電話と CUCM との間で交換されます。CUCM は次に、IP アドレスと、電話間で RTP 音声メディアを送

信するのに使用するポートを使用して、Red と Green の電話にシグナルを送ります。

2. Red および Green Cisco ファイアウォール は、シグナリングのインスペクションを行い、音声 RTP メディア ストリームで使用する IP アドアレスと UDP ポートを認識します。ファイアウォー

ルは、ピンホールを開いて、コールの間、2 つのエンドポイントとの間の通信を許可します。コー

ルが終了すると、ピンホールは動的に閉じられます。

3. 2 つのエンドポイント間の双方向 RTP メディアは、フュージョン ルータを通じて確立されます。

Cisco UnifiedCommunications Manager

M

CiscoIP

IP

IP Communicator

23

1

2

1

2262

83

91ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

デスクトップの統合された通信クライアントのバーチャライゼーション

このセクションでは、トラフィック フローとファイアウォール フィルタの要件を、このドキュメント

でテストする各 UC アプリケーションについて検証します。このセクションで重点的に扱うのは、ソフ

トフォンや IP ビデオ エンドポイントなどの統合された通信アプリケーションです。これらはデータ VPN に展開され、音声 VPN に展開されている IP 電話と通話するのに必要となります。次の UC アプ

リケーションとエンドポイントがテストされ、ドキュメントにまとめられました。

• Cisco IP Phone と Cisco IP Communicator • Cisco Unified Video Advantage

• Cisco Unified Personal Communicator

• Cisco Unity

• Cisco PSTN ゲートウェイ

これらのアプリケーションのそれぞれについて、コールを完了するのに必要なシグナリングと IP デー

タ フローの検証を行いました。サービス エッジ ファイアウォールでシグナリングを許可するのに必要

なフィルタを判断し、ファイアウォール インスペクションでシグナリングのインスペクションを行い、

ファイアウォール ピンホールを動的に開いたり閉じたりして、エンドポイント間で音声またはビデオ メディアを許可する方法を確認しました。

Cisco Unified IP Phone 7900 シリーズ電話と Cisco IP Communicatorこのセクションでは、Cisco Unified IP Phone 7900 シリーズと Cisco IP Communicator ソフトフォンの

テストについて説明します。Cisco IP Communicator は、Cisco Unified IP Phone 7900 シリーズ電話が

使用する IP プロトコルをエミュレートします。コール シグナリングとコール セットアップ データ フローは、Cisco IP Communicator とCisco Unified IP Phone 7900 シリーズ電話で同じであるため、まと

めて説明します。

データ フローを次の 3 つの部分に分けて説明します。

• IP Communicator または 7900 電話を CUCM に登録するのに必要なシグナリング

• 同じ VPN の IP Communicator または 7900 電話間のデータ フロー

• 異なる VPNs の IP Communicator または 7900 電話間のデータ フロー

エンドポイントの初期化と CUCM 登録

図 46 に、Cisco IP Communicator または Cisco Unified IP Phone 7900 シリーズ電話で、起動と CUCM への登録に必要となるシグナリングを示します。

92ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 46 音声エンドポイントの起動プロセス

図 46 では、Red VRF に 7960 デスク フォンが、Green VRF に IP Communicator があります。図 46 では、電話が 初に起動されたときのプロトコル フローが強調して示されています。起動プロセスは、

両方の電話で同じです。

1. 電話は、通常 DHCP を経由して有効な IP アドレスを受信します。DHCP サーバが返す情報の一部

にオプション 150 があり、これは TFTP サーバの IP アドレスです。この情報により、電話は指定

した TFTP サーバから自身の設定をダウンロードできます。

（注） 設定の CUCM 名が IP アドレス以外の場合、電話は DNS を使用して CUCM 名を IP アドレス

に解決します。これは、これには UDP ポート 53 への DNS トラフィックを許可する追加の

フィルタが必要になります。

2. 電話が CUCM に登録されました。この例では、Skinny（SCCP）プロトコルを使用します。SIP が代わりに使用された場合は、下記のアクセス フィルタが TCP ポート 2000 の代わりに、TCP ポートおよび UDP ポート 5060 を許可する必要があります。

ファイアウォールでこれらの操作に必要となるフィルタを、次の設定例に示します。これらのフィ

ルタは、図 46 の外にマークされているインターフェイスに適用されます。

!Define names used in IP access lists name 10.13.100.70 CUPS description CUPS Server name 10.13.100.5 DNS_DHCP_AD_Main name 10.13.100.20 CUCM_pub description CUCM publisher name 10.14.100.20 CUCM_sub description CUCM subscriber ! ! Permit DHCP and DNS access-list outside-vrf4-ACL extended permit udp any host DNS_DHCP_AD_Main eq bootps

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP ADM

VRF1 VRF2

CiscoIP

IP Communicator

IP

2 1 2 1

2262

84

93ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

access-list outside-vrf4-ACL extended permit udp any host DNS_DHCP_AD_Main eq domain ! ! Permit normal phone bootup - TFTP (UDP/69) and skinny signaling (TCP/2000) access-list outside-vrf1-ACL extended permit udp any host CUCM_pub eq tftp access-list outside-vrf1-ACL extended permit tcp any host CUCM_pub eq 2000

同じ VPN の IP テレフォニー エンドポイント間のコール フロー

このセクションでは、同じ VPN 内に展開されている IP テレフォニー エンドポイント間で、コールを

確立するのに必要な手順を検証します。

図 47 VPN 内の音声ストリーム

図 47 は、同じ VPN 内の IP テレフォニー エンドポイント間のコールのコール フローを示しています。

この例では、次のエンドポイントが示されています。

• 同じ VPN （Red）の 2 つの Cisco Unified IP Phone 7900 シリーズ電話

• 同じ VPN （Green）の 2 つの Cisco IP Communicator

ステップバイステップの手順は次のようになります。

1. 1 つの IP テレフォニー エンドポイントが他のエンドポイントをコールすると、コール電話と CUCM との間でコール シグナリング情報が交換されます。Cisco SCCP シグナリングのケースで

は、次のメッセージが送信されます。

– 発信側の電話は、ダイアルした番号を CUCM に送信します。

– CUCM は、両方の電話に対して、呼び出しを行い、発信側と着信側の情報を表示するシグナ

ルを送信します。

CiscoIP

IPIP

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP ADM

VRF1 VRF2

IP CommunicatorSoftphone

2 2

1

33

2262

85

94ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

– 着信側の電話が応答すると、CUCM は両方の電話に StationOpenReceiveChannel を送信しま

す。これは、RTP メディア ストリームに関する情報を提供し、電話に対して UDP ポートを開

いて他の電話からの RTP メディア ストリームを受信するよう要求するものです。

– それぞれの電話が、IP 電話が RTP パケットをリスニングする IP アドレスとポート番号を提供

する StationOpenReceiveChannelAck に応答します。

– CUCM が それぞれの電話からの StationOpenReceiveChannelAck を受信すると、CUCM は StationStartMediaTransmission を別の電話に送信して、StationOpenReceiveChannelAck で受

信した IP アドレスとポートに対して、音声 RTP メディアのストリーミングを開始するよう通

知します。

2. ファイアウォール フィルタは、コール シグナリング プロトコルを許可し、ファイアウォールはイ

ンスペクションを実行して、プロトコル アノマリー検出とアプリケーションおよびプロトコル ステート追跡を行います。コールは同じ VPN に属するエンドポイント間で確立されたものであるた

め、メディア トラフィックはファイアウォールを通過する必要がなく、ファイアウォール イン

ターフェイスの外側と内側の間でピンホールは開かれません。

3. 2 つの IP テレフォニー エンドポイントが、自身の VPN 内でルーティングを使用してピアツーピア

音声 RTP メディアを互いに送信します。

異なる VPN の IP テレフォニー エンドポイント間のコール フロー

図 48 は、IP Communicator が Green データ VPN にあり、デスク IP 電話が Red 音声 VPN にある場合

の一般的なシナリオを示しています。

図 48 VPN 間音声ストリーム

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP ADM

VRF1 VRF2

CiscoIP

IP Communicator

IP

2 2

2

1

2262

86

95ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

音声データ RTP が、異なる VPN にある 2 つの電話の間で流れるようにするには、ファイアウォールを

通過して、フュージョン ルータによりルーティングされる必要があります。次のイベント シーケンス

が必要となります。

1. 1 つの IP テレフォニー エンドポイントが他のエンドポイントをコールすると、コール電話と CUCM との間でコール シグナリング情報が交換されます。コール シグナリングは、2 つの電話

コールが同じ VPN で行われた場合の例で説明したものと同じです。

– 発信側の電話は、ダイアルした番号を CUCM に送信します。

– CUCM は、両方の電話に対して、呼び出しを行い、発信側と着信側の情報を表示するシグナ

ルを送信します。

– 着信側の電話が応答すると、CUCM は両方の電話に StationOpenReceiveChannel を送信しま

す。これは、RTP メディア ストリームに関する情報を提供し、電話に対して UDP ポートを開

いて他の電話からの RTP メディア ストリームを受信するよう要求するものです。

– それぞれの電話が、IP 電話が RTP パケットをリスニングする IP アドレスとポート番号を提供

する StationOpenReceiveChannelAck に応答します。

– CUCM が それぞれの電話からの StationOpenReceiveChannelAck を受信すると、CUCM は StationStartMediaTransmission を別の電話に送信して、StationOpenReceiveChannelAck で受

信した IP アドレスとポートに対して、音声 RTP メディアのストリーミングを開始するよう通

知します。

2. ファイアウォール フィルタは、コール シグナリング プロトコルを許可し、ファイアウォールはイ

ンスペクションを実行して、プロトコル アノマリー検出とアプリケーションおよびプロトコル ステート追跡を行います。

– それぞれのファイアウォールは、電話 VPN と共有サービス VPN のフュージョン ルータとの

間でファイアウォールを通過するコール メディアのフローを確認します。

– ファイアウォールは、ピンホールを開いて、電話から CUCM に送信された StationOpenReceiveChannelAck と CUCM から電話に送信された StationStartMediaTransmission にある IP アドレスと UDP ポートの間でやり取りされるトラ

フィックを許可します。

3. 2 つの IP テレフォニー エンドポイントが、デフォルト ルート使用します。これは、フュージョン ルータによってアドバタイズされ、各 VPN に挿入されて、ファイアウォール ピンホールを通じて

トラフィックをフュージョン ルータに送信します。フュージョン ルータは、他のファイアウォー

ルを通じて、トラフィックを他の VPN の IP テレフォニー エンドポイントに転送します。

このシナリオで重要なポイントは、各ファイアウォール コンテキストの内部と外部のインターフェイ

ス間でRTP メディア データ トラフィックのフォローを許可するように、ファイアウォール ホールを設

定する必要がないことです。これは、コールをセットアップする SIP シグナリングまたは SCCP シグ

ナリングに対してファイアウォールによるインスペクションが行われ、RTP メディア データ トラ

フィックのための経路を動的に開くことができるためです。そのトラフィックで使用するファイア

ウォール ピンホールは、コールが終了すると動的に閉じられます。

SIP と Skinny インスペクションは、Cisco Firewall Service Module と ASA では、デフォルトで有効と

なっています。次の設定例は、SIP おおよび SCCP インスペクションを担当する命令文です。

policy-map global_policyclass inspection_defaultinspect dns preset_dns_mapinspect ftpinspect h323 h225inspect h323 rasinspect netbiosinspect rshinspect rtspinspect skinny

96ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

inspect esmtpinspect sqlnetinspect sunrpcinspect tftpinspect sipinspect xdmcpinspect icmp!service-policy global_policy global

概要：Cisco Unified IP Phone 7900 シリーズ電話と Cisco IP Communicator

Cisco Unified IP Phone 7900 シリーズ電話 と Cisco IP Communicator との間のコールでは、フィルタ

を使用してファイアウォールを設定して、コール シグナリング プロトコルを許可し、音声エンドポイ

ントが CUCM に正常に登録されるようにする必要があります。この時点で、次の 2 つのシナリオが考

えられます。

• 音声コールが 同じ VPN の 2 つの IP テレフォニー エンドポイント間のものである場合、コール ルーティングは VPN 内にとどまり、メディア ストリームはファイアウォールを通過する必要があ

りません。

• コールが異なる VPN の IP テレフォニー エンドポイント間のものである場合、Cisco ファイア

ウォールのデフォルトの動作では、コール シグナリングのインスペクションを行い、トラフィッ

クが VPN 間のフュージョン ルータによってルーティングされるため、ピンホールを動的に開いて

各ファイアウォールを通過するトラフィックを許可します。

Cisco Unified Video AdvantageCisco VT Advantage は、Cisco IP Phone 7940、7960、および 7970（および以降）モデルに、ビデオ テレフォニー機能を提供します。Cisco VT Advantage ソフトウェアを Cisco VT Camera（USB カメ

ラ）と共に使用すると、Cisco IP 電話に接続された PC で、ボタンやマウスのクリック操作なしで、電

話コールにビデオを追加できます。Cisco Call Manager に登録されると、Cisco VT Advantage に対応

した Cisco IP 電話に、IP ビデオ電話としての完全な機能が備わります。ビデオ コールでは、コール転

送、転送、保留、消音などの補足機能も利用可能で、すべて Cisco IP 電話から起動できます。

Cisco VT Advantage では、会議室で使用する汎用のビデオ会議ソリューションではなく、デスクトッ

プ間の IP ビデオ テレフォニー環境を想定しています。ユーザは、Cisco Unified Video Advantage ビデ

オ コールを、Cisco Unified IP Phone または Cisco IP Communicator のいずれかに設定できます。

通常の使用では、Video Advantage は PC のシステム トレイに 小化されて実行されます。別の Video Advantage ユーザからコールされると、音声コールが接続された時点でビデオが自動的に表示されま

す。CUVA コールの確立を可能にするイベント シーケンスを次に一覧します。

• CUVA 初期化

• CUVA コール シグナリング

• CUVA コール メディア フロー：VPN 内

• CUVA コール メディア フロー：VPN 間

CUVA の初期化

図 49 は、Video Advantage が初期されて操作可能になるために必要なプロトコルのフローを示してい

ます。この場合は、Cisco IP 電話がすでに初期化されており、CUCM に登録されていると仮定してい

ます。CUCM では、この電話がビデオ対応であることを示すチェックボックスが設定されています。

97ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 49 CUVA クライアントの初期化

（注） Cisco Unified Video Advantage は、Cisco Unified IP Phone または Cisco IP Communicator と共に使用

できます。

CUVA Desk Phone の使用方法

図 49 では、Cisco Unified Video Advantage は 7960 に直接接続されています。Video Advantage が Green データ VRF に、Desk Phone が Red 音声 VRF にあります。

• Video Advantage は、PC で設定を行う必要がありません。したがって、音声コールで使用する電

話の IP アドレスを取得する必要があります。これは、直接接続されている Desk Phone によって送

信されるリンク層 CDP アドバタイズメントをリスニングすることで取得されます。CDP はレイヤ 2 プロトコルですが、バーチャライゼーションによりレイヤ 2 のセグメンテーションではなくレイ

ヤ 3 のセグメンテーションが提供されるため、エンドポイントが異なる仮想 VPN にある場合でも、

エンドポイント間で直接 CDP の送信が可能です。

• Video Advantage が IP 電話に直接付加されている IP アドレスを取得すると、Cisco Audio Session Tunnel（CAST）プロトコルを使用して、電話との TCP セッションを確立します。Video Advantage と Desk Phone が異なる VPN にあるため、CAST セッションはファイアウォールを通

過して、フュージョン ルータによってルーティングされる必要があります。

（注） CUVA を実行する PC は、デスクフォン モードで使用する IP 電話に直接接続して、登録に必

要なリンク層 CDP フレームを受信できるようにしておく必要があります。

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP ADM

CiscoIP

CDP CiscoUnified Video

Advantage

1

2

VRF1 VRF2

IP

2262

87

98ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

• CAST プロトコルを 2 つの VPN 間で通過させるためのポート 4224 を許可するために、Green データ VPN のフロントエンドとなるファイアウォール コンテキストの外部インターフェイスに、

フィルタが必要となります。CAST 通信は CUVA クライアントによって開始されるため、CUVA VPN のファイアウォールの外部インターフェイスにだけ、フィルタを適用する必要があります。

CAST プロトコルが IP 電話 VPN にルーティングされると、通常は permit-all フィルタにより、内

部からのトラフィックを通過させます。これにより、返信トラフィックを動的に許可する接続が確

立されます。CUVA VPN の外部インターフェイスで CAST を許可するのに使用するフィルタを、

次の設定例に示します。

access-list outside-vrf2-ACL remark Permit CUVA (Video Advantage) CAST protocol (TCP Port 4224) access-list outside-vrf2-ACL extended permit tcp any any eq 4224

CUVA ソフトフォンの使用方法

物理的な Cisco Unified IP Phone 7900 シリーズ電話の代わりに、CUVAを Cisco IP Communicator と共に使用できます。この場合は、CUVA と IP Communicator を同じ PC 上のソフトウェア アプリケー

ションとして実行します。そのため、CUVA と IP Ccommunicator 間の通信は内部通信となり、そのト

ラフィック フローは図 49 に示すように、ネットワーク上では発生しません。

CUVA コール シグナリング

図 50 は、コールのセットアップに使用するVideo Advantage のシグナリングを示しています。

図 50 CUVA シグナリング

CiscoIP

IPIP

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP ADM

VRF1 VRF2

2

1

Cisco Unified VideoAdvantage

2262

88

99ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 50 では、Red 音声 VRF に 2 つの Cisco IP 電話があり、Gren データ VRF にある 2 台の PC に直接

接続されています。図 50 は、Cisco IP 電話の 1 つが他方を呼び出した場合に起こるフローを示してい

ます。

わかりやすくするために、図 50 では 2 つの電話間で音声コールを確立するコール シグナリングが示さ

れていません。コールの音声部分となるコール シグナリングは、「Cisco Unified IP Phone 7900 シリー

ズ電話と Cisco IP Communicator」 で示されているものと同じです。

Cisco Unified IP Phone は、CUCM と CUVA 間のシグナリング プロキシとして機能します。ビデオ シグナリングは、SIP または SCCP を経由して送信されます。これは、CAST プロトコルを使用して、シ

グナリングを CUVA クライアントにリレーします。両方の IP 電話を、CUCM でビデオ機能を有効に

して設定する必要があります。電話と CUCM 間のビデオ シグナリングは、SIP または SCCPを経由し

て送信されます。各電話はビデオ シグナリング プロキシとして機能するため、CAST プロトコルを使

用して、電話と CUVA PC 間のビデオ シグナリングのリレーを行います。

電話と PC が異なる VPN にあるため、CAST メッセージ プロトコルは、ファイアウォールを通過して VPN 間でフュージョン ルータによってルーティングされる必要があります。

ビデオ シグナリングは音声シグナリングと同様で、コールの確立は次のように行われます。

• SIP または SCCP を使用して、OpenMultiMediaReceiveChannelMessage が、CUCM から電話に

送信されます。電話は、CAST プロトコルを使用して、このメッセージの CUVA エンドポイント

に対するプロキシとして機能します。

• CUVA エンドポイントは、CAST プロトコルを使用して、

OpenMultiMediaReceiveChannelAckMessage を電話に送信します。電話は、SIP または SCCP プロトコルを使用して、このメッセージの CUCM に対するプロキシとして機能します。

OpenMultiMediaReceiveChannelAckMessage には、CUVA エンドポイントが開いてビデオ メディアをピア CUVA エンドポイントから受け取るための IP アドレスと UDP ポートが含まれてい

ます。

• CUCM が OpenMultiMediaReceiveChannelAckMessage を 1 つのエンドポイントから受け取ると、

StartMultiMediaTransmissionMessage を別のエンドポイントに送信して、RTP ビデオ ストリーム

の指定した IP アドレスと UDP ポート（CUVA ビデオ メディアではポート 5445 が常に使用され

る）への送信を開始するよう指示します。このメッセージは、SIP または Skinny を通じて CUCM から電話に送信され、CAST プロトコルを使用して CUVA エンドポイントにリレーされます。

CUVA 初期化のための CAST を許可するのに使用する CUVA VPN の外部インターフェイスにある同

じファイアウォール アクセスリストを使用して、コーリング シグナリングの CAST を許可します。

CUVA コール メディア フロー：VPN 内

図 51 は、CUVA コールに含まれる IP 電話と CUVA エンドポイント間の RTP 音声およびビデオ メディア フローで、両方のエンティティが同じ VAN 内に展開されているという特殊なケースを示してい

ます。

100ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 51 VPN 間の CUVA コール

• 2 つの電話が同じ VPN 内にあるため、電話間の RTP 音声パケットが Red VPN 内でルーティング

されます（ファイアウォールによるインスペクションまたはフュージョン ルータによるルーティ

ングは不要）。

• 同様に、この例では 2 つの PC が同じデータ VPN 内にあり、PC 間の RTP ビデオ パケットが Green VPN 内でルーティングされます。

CUVA コール メディア フロー：VPN 間

図 52 は、わずかに複雑な CUVA 展開のコール メディア フローを示しています。この例では、全社規

模の音声 VPN が 1 つありますが、データ VPN は複数存在します。

CiscoIP

IPIP

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP ADM

VRF1 VRF2

Cisco Unified VideoAdvantage

1RTP

2UDP

2262

89

101ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 52 VPN 間の CUVA コール

• Red 音声 VPN 内で、音声 RTP パケット フローは、前の例と同じように直接流れます。

• コールを確立した Cisco IP 電話に関連づけられたビデオ エンドポイントは、異なるデータ VPN にあります。このケースでの RTP ビデオ メディアは、ファイアウォールを通過して、フュージョン ルータによってルーティングされる必要があります。このため、別のフィルタをファイアウォール コンテキストの外部インターフェイスに追加して、両方のデータ VPN を保護して、Video Advantage の RTP データが使用する UDP ポートを許可する必要があります。Video Advantage は、そのメディア トラフィックの送信元と宛先に 1 つのポートだけを使用することから、ファイ

アウォールで開く必要があるのは、UDP ポート 5445 だけとなります。

Cisco ファイアウォールは現在 CAST プロトコルのインスペクションを行っていないため、CUVA が開始するビデオ メディアに、必要なフィルタを手動で設定する必要があります。各 CUVA エンドポイ

ントが方向性のない RTP ビデオ メディア ストリームを他のエンドポイントに対して確立するため、両

方の CUVA クライアント VPN ファイアウォールの外部インターフェイスにフィルタを適用する必要が

あります。VPN 間で CUVA ビデオ RTP データを許可するのに必要なファイアウォール ACL には、次

のものがあります。

! Permit CUVA video data between VPNs access-list outside-vrf3-ACL extended permit udp any any eq 5445

CUVA の概要

ビデオ対応として設定され、CUVA が追加されたワークステーションを持つ 2 つの電話間にコールが

送信されると、電話は音声エンドポイントとしての役割を果たします。この場合は、データ デバイス

がビデオ エンドポイントを表します。

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP ADM

VRF1 VRF2 VRF3

CiscoIP

1 2

IPIP

CUVA CUVA

UDPRTP

2262

90

102ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

すべての CUCM シグナリングが、電話との間でやり取りされます。電話は、CAST プロトコルを通じ

て、ワークステーションとの間のビデオ シグナリングのプロキシとして機能します。Cisco ファイア

ウォールは現在 CAST プロトコルのインスペクションを行っていないため、CUVA が開始するビデオ メディアに、必要なフィルタを手動で設定する必要があります。

音声メディアは音声エンドポイント間を直接流れ、ビデオ メディアはビデオ エンドポイント間を直接

流れます。

Cisco Unified Personal CommunicatorCisco Unified Personal Communicator は、頻繁に使用される通信アプリケーションとサービスを、1 つの統合されたクライアントに透過的に統合します。これを使用すると、PC または Mac の使いやすいイ

ンターフェイスから、強力な通信ツールであるソフトフォン、Presence、Instant Messaging、ビジュア

ル ボイス メール、クリック ツー コール、従業員ディレクトリ、通信履歴、ビデオ、Web 会議などに、

すばやく簡単にアクセスできるようになります。

IP テレフォニーで使用すると、CUPC は次の 2 つのモードにいずれかで動作します。

• ソフトフォン モード

ソフトフォン モードでは、CUPC は IP テレフォニー エンドポイントとなります。SIP シグナリン

グを使用して CUCP との通信を行い、他の音声エンドポイントとの間で RTP 音声メディア スト

リームを確立します。

• デスクフォン モード

デスクフォン モードでは、CUPC はデスクトップ Cisco Unified IP Phone を制御して、コールの作

成、受信、または統合を行うのに使用されます。

次に、CUVA コール確立の次のステージを見ていきます。

• CUPC の初期化

• CUPC シグナリングとコール フロー：デスクフォン モード

• CUPC シグナリングとコール フロー：ソフトフォン モード

• CUPC シグナリングとコール フロー：ソフトフォン ビデオ コール

• CUPC シグナリングとコール フロー：ソフトフォン ビデオ コール、VPN 間

• CUPC シグナリングとコール フロー：Instant Messaging

CUPC の初期化

このセクションでは、CUPC がワークステーション上で起動されたときに発生するデータ フローにつ

いて見ていきます。

103ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 53 CUPC 初期化プロセス

図 53 は、CUPC を完全に起動するのに必要な手順を重点的に示しています。

1. CUPC は、HTTPS を使用して CUPS サーバに安全な方法でログを記録します。CUPC は、

Presence Server から TFTP サーバの IP アドレスを取得します。

2. 次に、CUPC は 他の電話と同様に、設定ファイルを TFTP でダウンロードします。

3. Cisco Unified Personal Communicator は、企業の Lightweight Directory Access Protocol（LDAP）バージョン 3 ディレクトリにアクセスして、連絡先リストの各連絡先でディレクトリ検索を行っ

て、追加の連絡先情報（名、姓、電話番号など）を提供します。

4. CUPC は SIP プロトコルを使用して、CUCM サーバと CUPS サーバにプレゼンス情報を登録しま

す。CUPC は SIP シグナリング プロトコルを使用します。Skinny（SCCP）は使用できません。

5. CUPCクライアントがデスクフォン モードで使用された場合は、CUCM との間で CTI 接続が確立

されます。CTI プロトコルを使用すると、CUPC はデスクトップ Cisco Unified IP Phone を制御し

て、コールの作成、受信、統合を行うことができます。制御する電話を直接追加する必要がありま

せんが、CUCM 設定で CUPC ユーザに関連づける必要はありません。

（注） Cisco Unified Presence は、Session Initiation Protocol （SIP）プレゼンス エンジンと SIP プロキシ サーバ機能を Cisco Unified Personal Communicator に提供します。プレゼンス エンジンは、SIP Instant Messaging と Presence Leveraging Extensions（SIMPLE）を使用して、Cisco Unified Personal Communicator にユーザとデバイスのステータス情報（たとえば、使用可能、外出、休憩中など）を提

供します。

プレゼンス エンジンは、各ユーザの優先通信方法（Instant Message、E メール、音声、ビデオ）と 連絡先リストを格納します。Cisco Unified Presence は、Cisco Unified Personal Communicator のログイ

Cisco UnifiedCommunications

ManagerCiscoUnified

PresenceTFTP DNSDHCP AD

VRF1

1

23M

4

5

PersonalCommunicator

VRF2

2262

91

104ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

ン認証を行い、HTTP と HTTPS で Simple Object Access Protocol （SOAP）を使用して、Cisco Unified Personal Communicator に設定情報を提供します。プロキシ サーバは、クライアントに登録と

ルーティングのサポートを提供します。これらはすべて SIP ベースとなります。Cisco Unified Personal Communicator は、このプロキシ サーバとの間で SIP メッセージの送受信を行います。これ

らの SIP メッセージは、プレゼンス情報とデータベース変更通知のためのものです。Cisco Unified Personal Communicator は、Instant Messaging を使用して SIP メッセージを（プロキシ経由で）他の Cisco Unified Personal Communicator クライアントに送信します。

次の設定例は、CUPC の初期化を可能にするために、CUPC VPN のフロントエンドとなるファイア

ウォール コンテキストの外部インターフェイスに追加する必要のある、すべてのフィルタを示してい

ます。

name 10.13.100.70 CUPS description CUPS Servername 10.13.100.5 DNS_DHCP_AD_Mainname 10.13.100.20 CUCM_pub description CUCM publishername 10.14.100.20 CUCM_sub description CUCM subscriber!object-group protocol TCPUDPprotocol-object udpprotocol-object tcp!! 1. Permit HTTPS for CUPC login to CUPS (TCP port 443)access-list outside-vrf1-ACL extended permit tcp any host CUPS eq https! 2. Permit IP phone TFTP configuration download (UDP port 69)access-list outside-vrf1-ACL extended permit udp any host CUCM_pub eq tftp! 3. Permit LDAP communication between CUPC and LDAP DB (TCP port 389)access-list outside-vrf1-ACL extended permit tcp any host DNS_DHCP_AD eq ldap! 4. Permit SIP signaling between CUPC and CUCM & CUPS (TCP/UDP port 5060)access-list outside-vrf1-ACL extended permit object-group TCPUDP any host CUCM_pub eq sipaccess-list outside-vrf1-ACL extended permit object-group TCPUDP any host CUPS eq sip! 5. Permit CTI communication between CUPC in deskphone mode and CCM (TCP port 2748)access-list outside-vrf1-ACL extended permit tcp any host CUCM_pub eq ctiqbe

CUPC シグナリングとコール フロー：デスクフォン モード

このセクションでは、CUPC を使用して、デスクトップ Cisco Unified IP Phone を制御してコールを実

行するときに発生するフローについて説明します。

105ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 54 デスクフォン モードの CUPC

図 54 は、CUPC を使用してデスクフォンを制御するときの、シグナリングとコール フローを示してい

ます。この使用例では、CUPC Outlook ツールバーが提供するクリック ツー ダイアル機能を使用して

います。Outlook クリック ツー ダイアルを CUPC ワークステーションで使用すると、CTI シグナリン

グが CUCM に送信され、ローカル デスクフォンとリモートの電話で呼び出し音が同時に鳴ります。リ

モートの電話が応答すると、デスクフォンがコールに使用されて、CUPC は使われなくなります。

1. この処理を実行するために、CUPC が Computer Telephony Integration （CTI）を通じて CUCM にシグナルを送信します。

2. 次に、CUCM が Skinny （または SIP）を通じて、受信側の Cisco IP Phone にシグナルを送信しま

す。

3. 接続されると、この例に示すように、同じ音声 VRF の一部として展開されている場合に、2 つの IP 電話間でコール メディアのフローが発生します。

ここで、CUPC に関して、CUPC が制御する CUPC とデスクフォンの関係は CUCM で設定され、両

者間に物理的なイーサネット接続が不要である点にも注意が必要です。この論理的な関係は、図 54 のドットの付いた行で示されています。

CTI フロー シグナリングは、ファイアウォールに送られ、初期化セクションの 5 番のフィルタでフィ

ルタリングされます。さらに、デスクフォンの制御に使用される SCCP または SIP シグナリングに対

して、ファイアウォールによるインスペクションが行われますが、この例では 2 つのデスクフォンが同

じ VPN にあり、その RTP 音声メディア トラフィックはファイアウォールを通過する必要はありませ

ん。

CiscoIP

IP

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP ADM

VRF1 VRF2

1

PersonalCommunicator

3

IP

2

2262

92

106ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

CUPC シグナリングとコール フロー：ソフトフォン モード

ソフトフォン モードでは、CUPC は IP テレフォニー エンドポイントとなります。SIP シグナリングを

使用して CUCP との通信を行い、他の音声エンドポイントとの間で RTP 音声メディア ストリームを確

立します。

図 55 ソフトフォン モードの CUPC

図 55 では、CUPC がスタンドアロン ソフトフォン モードで使用されています。

1. CUPC は、SIP を使用して CUCM にシグナルを送信します。CUPC はシグナリングで SIP だけを

使用し、Skinny は現在サポートの対象外です。

2. CUCM は CUPC と呼び出しを行っているデスクフォンにシグナルを送信します。CUCM は、

CUPC に対しては SIP を使用し、デスクフォンに対しては SIP または Skinny を使用します。

3. 後に、RTP メディア ストリームは、2 つの音声エンティティ間を流れます。

コールは Red 音声 VPN のデスクフォンと、Green データ VPN のCUPC 間のものであるため、メディ

ア フローはファイアウォールとフュージョン ルータを経由する必要があります。

このケースでは、初期化セクションで定義されているフィルタによって、SIP と Skinny フローがファ

イアウォールを通過します。さらに、SIP と SCCP シグナリングに対してインスペクションが行われ、

RTP データ フローはコールが継続する間、動的に許可されます。

CUPC シグナリングとコールフロー：VPN 間のソフトフォン ビデオ コール

CUPC を Webcam を備えたワークステーションで使用する場合は、ビデオ電話として使用できます。

このセクションでは、同じ VPN の CUPC ワークステーション間でビデオ コールが行われたときに発

生するフローを検証します。

CiscoIP

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP AD

VRF1 VRF2

12a

3

PersonalCommunicator

IP

M2b

2262

93

107ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 56 VPN 内のソフトフォン モードの CUPC を使用したビデオ コール

図 56 は、同じ Green VRF 内の 2 つの CUPC クライアント間のソフトフォン コールを示しています。

1. 1 つの CUPC クライアントが別のクライアントを呼び出します。呼び出しを要求する SIP シグナリ

ングが CUPC に送られます。

2. CUCM と 2 つの CUPC エンドポイント間の SIP シグナリング フローが、音声コールのセットアッ

プを行います。

3. 両方の CUPC が同じ Green データ VPN 内にあるため、2 つの CUPC 間の RTP 音声は、VPN 内でルーティングされます。

4. CUCM は、コールが 2 つのビデオ対応クライアント間のものであることを認識し、CUPC クライ

アントに、互いにビデオ送信を開始するよう指示します。ビデオが起動され、VPN 内でルーティ

ングされます。

音声とビデオ RTP ストリームが同じ VPN 内でルーティングされるため、データ ストリームはサービ

ス エッジを通過せず、トラフィックのインスペクションは行われず、追加のフィルタも不要です。

CUPC シグナリングとコールフロー：VPN 間のソフトフォン ビデオ コール

このセクションは、CUPC エンドポイントが 2 つの異なる VPN にあること以外は、前のセクションと

同様です。

CiscoIP

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP AD

VRF1 VRF2

1

3

PersonalCommunicator

IP

M2

4

2262

94

108ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 57 VPN 間のソフトフォン モードの CUPC を使用したビデオ コール

図 57 は、異なる VPN に展開された 2 つの CUPC クライアントを示しています。

1. 1 つの CUPC クライアントが別のクライアントを呼び出します。呼び出しを要求する SIP シグナリ

ングが CUPC に送られます。

2. CUCM と 2 つの CUPC エンドポイント間の SIP シグナリング フローが、音声コールのセットアッ

プを行います。

3. 各 VPN のファイアウォールが SIP シグナリングのインスペクションを行い、ピンホールを動的に

開いて、音声 RTP メディア ストリームを通過させるのに使用する UDP ポートを許可します。

4. 両方のエンドポイントが、CUCM でビデオ対応として設定されています。CUCM は SIP シグナリ

ングを CUPC クライアントに送信して、互いにビデオを開始するよう指示します。各 VPN のファ

イアウォールが SIP シグナリングのインスペクションを行い、ピンホールを動的に開いて、ビデオ RTP メディア ストリームを通過させるのに使用する UDP ポートを許可します。

CUPC シグナリングとコール フロー：Instant Messaging

Instant Messaging のサポートにより、CUPC ユーザは他の Cisco Unified Personal Communicator ユー

ザとリアル タイムでチャットできるようになり、時間の節約になり、不在による行き違いも少なくな

ります。

Cisco UnifiedCommunications

Manager

TFTP DNSDHCP AD

VRF1 VRF2

1

M

2

3

4

PersonalCommunicator

PersonalCommunicator

2262

95

109ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 58 Instant Messaging と CUPC

Cisco Unified Personal Communicator は、SIMPLE プロトコルを使用して、Instant Message を他の CUPC ユーザに送信します。これは、Cisco Unified Presence サーバがサポートして、CUPC クライア

ント間でメッセージのリレーを行うものです。

1. Green VRF にある CUPC が SIP/SIMPLE Instant Message を Cisco Unified Presence サーバの SIP プロキシ機能に送信します。

2. 次に、CUPS サーバは Instant Message を Red VRF にある 2 つの CUPC にリレーします。

CUPC クライアント間の Instant Message には、SIP プロトコルが使用されます。SIP Instant Message は、CUPC の初期化で定義される SIP フィルタにより、デフォルトで許可され、インスペクションが

行われます。

CUPC の概要

Cisco Unified Personal Communicator は、頻繁に使用される通信アプリケーションとサービスを、1 つの統合されたクライアントに透過的に統合します。強力な通信ツールであるソフトフォン、Presence、Instant Messaging、ビジュアル ボイス メール、クリック ツー コール、従業員ディレクトリ、通信履

歴、ビデオ、Web 会議などに、すばやく簡単にアクセスできるようになります。

このセクションでは、CUPC メッセージのフローと、次の統計的に定義されたフィルタが CUPC クラ

イアントの正常な動作を許可することに焦点を当てます。

• CUPC VPN から共有サービス VPN の特定の宛先サーバに対する HTTPS、TFTP、SIP、LDAP、および CTI トラフィックを許可します。

Cisco UnifiedCommunications

ManagerCiscoUnified

PresenceTFTP DNSDHCP AD

VRF1 VRF2

1

M

2

PersonalCommunicator

PersonalCommunicator

2262

96

110ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

• SIP シグナリングのファイアウォール インスペクションは、さまざまな VPN の音声エンドポイン

ト内と音声エンドポイント間での通信がテストされているアプリケーションを許可するのに十分な

ものです。

（注） CUPC バージョン 1.2 は、このドキュメントでテストされている次の 2 つの機能をサポートしていま

す。

- Web 会議：他者とのプレゼンテーションのような共有コンテンツを共有する通知が出された瞬間に、

Web 会議セッションを起動します

- 音声メッセージ：Cisco Unity または Cisco Unity Connection ボイス メール メッセージにアプリケー

ションからアクセスし、メッセージの表示、再生、並べ替え、および削除を行います。これらの機能

は、TCP 143（Web 会議）および TCP 80（ボイス メッセージ）が有効になっている場合の追加フィル

タで必要な TCP ポートを使用します。

また、テストが完了して以降に CUPC バージョン 7.0 がリリースされています。CUPC 7.0 は、セキュ

アなボイス メール メッセージの復号とCUPC による再生が可能です。これには、CUPC が追加フィル

タで必要となる次のポートと通信できる必要があります。

- 7993：特別な IMAP ポート （Cisco Unity Connection） - 993：SSL （IMAP の交換）

- 443：HTTPS （Cisco Unity）

Unity ボイスメール

Unity ボイスメールにアクセスすることは、Unity サーバに音声コールを送信するための主要なポイン

トです。Unity サーバは、CUCM との共有サービス VPN にあります。Unity を CUCM と共に配置す

ることで、一貫性のあるコール制御と、すべての音声クライアントに対するメッセージング アクセス

が可能になります。

111ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

図 59 Unity ボイスメールの統合

1. IP 電話は、コールをソフトフォンに発信します。エンドポイントと CUCM 間の SIP または Skinny コール シグナリングにより、電話で呼び出し音が鳴ります。

2. 着信側の電話が応答しない場合、CUCM はそのコールを Unity Voicemail にリダイレクトするよう

設定されています。CUCM は Unity に対しては SCCP シグナリングを、Unity Express に対しては CTI を使用してシグナリングを行います。CUCM と Unity は同じ VPN に存在するため、このシグ

ナリングは設定不要であるか、サービス エッジのファイアウォールによるインスペクションを受

けます。

3. CUCM は、コーリング エンドポイントと Unity 間で標準の SCCP または SIP シグナリングを使用

して、RTP 音声メディア コールを確立します。

4. コールが進行します。Unity はプロンプトを行い、メッセージの再生は、サーバから音声エンドポ

イントに RTP 音声メディア パケットとして送られます。Unity ボイス プロンプトに対するエンド

ユーザのキーパッドの応答が、dual-tone multi-frequency（DTMF）タッチトーンとして Unity に送られます。発信側の電話と Unity との間の DTMF タッチトーンは、通常は SCCP または SIP コール シグナリングを通じてアウトオブバンドで CUCM にリレーされますが、個別の RTP ペイ

ロード タイプを使用して、RTP 音声データ ストリーム内で実行するオプションもあります。

IP 電話の Unity ボイスメールへのアクセスを許可するのに、ファイアウォールのホールを設定する必

要はありません。これは、コールをセットアップする SIP または Skinny シグナリングがファイア

ウォールによるインスペクションを受けるためで、そのコールが使用する特定の IP アドレスと UDP ポートについて、ファイアウォールは動的に開きます。そのトラフィックで使用するファイアウォール ピンホールは、コールが終了すると動的に閉じられます。

Cisco UnifiedCommunications

Manager

UnityM

VRF1 VRF2

CiscoIP

IP Communicator

IP

2

3

1 1

2

2262

97

112ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

PSTN ゲートウェイ アクセス

PSTN ゲートウェイは、公衆電話ネットワークへのコールの発信または着信、追加に使用されます。

PSTN ゲートウェイは、コール シグナリングと、IP ネットワークと PSTN で使用される転送プロトコ

ルの変換を行います。MGCP と H323 は、CUCM と PSTN ゲートウェイ間のシグナリングで使用され

る も一般的な制御プロトコルです。MGCP と H323 はこのドキュメントでテストされています。

（注） このネットワーク設計では、VRF 対応の PSTN ゲートウェイは使用しません。代わりに、PSTN ゲー

トウェイと、物理的な Cisco IP 電話として同じ VLAN/VRF に属するイーサネット インターフェイス

を接続します。物理的な IP 電話が PSTN ゲートウェイと同じ VRF に存在するため、PSTN ゲートウェ

イとの間で RTP 音声パケットを直接やり取りできます。他の VPN にある音声エンドポイントは、サー

ビスエッジを通過して PSTN ゲートウェイと通信を行う必要があります。

このセクションでは、次の使用ケースについて説明します。

• PSTN ゲートウェイとして同じ VPN に存在する物理的な IP 電話からの PSTN ゲートウェイ アク

セス

• 異なる VPN に存在するソフトフォンから PSTN ゲートウェイへの PSTN ゲートウェイ アクセス

PSTN ゲートウェイ アクセス：VPN 内

図 60 PSTN ゲートウェイ アクセス（VPN 内）

1. Red 電話が、PSTN 上の外部電話の番号をダイアルします。CUCM への Skinny または SIP シグナ

リングを使用して、コールのセットアップを行います。

Cisco UnifiedCommunications

Manager

UnityM

VRF1 VRF2

CiscoIP

PSTNGW

IP Communicator

IP

2

3

1

PSTN 4

2262

98

113ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

仮想ネットワーク インフラストラクチャにおける音声テクノロジー

2. コール マネージャ ダイアル プランにより、ダイアルされた番号が PSTN ゲートウェイを通過可能

であるかが判断され、PSTN ゲートウェイへの MGCP または H323 シグナリングを使用して、Red 電話と外部電話との間のコールのセットアップが行われます。外部電話へのコールのセットアップ

が行われるときに、PSTN ゲートウェイはシグナリング プロキシとして機能します。

3. Red 電話と PSTN ゲートウェイは、CUCM によってシグナリングが行われるコール セットアップ

情報を使用して、互いのコールのセットアップを行います。IP 電話と PSTN ゲートウェイが同じ VPN に存在するため、ファイアウォールを通過する必要はありません。

4. PSTN ゲートウェイは、IP ネットワークと PSTN ネットワーク間のコールのリレーで、プロキシ

として機能します。

音声プロンプトに応答したエンドユーザのキーパッドが、DTMF タッチトーンとして Unity に送信さ

れます。デフォルトでは、ゲートウェイはこれらのトーンを音声 RTP ストリーム内で送信します。音

声が圧縮されないまま送信される場合は、これらのトーンが元の状態で着信します。しかし、G.729 コーデックなどを使用して音声が圧縮された場合は、トーンが歪んだり、その一部が失われる場合があ

ります。DTMF リレーは、これらのトーンを残りの音声から分離して別の方法で送信することで、こ

の問題に対処しています。DTMF トーンは、個別の RTP ペイロード タイプを使用して、RTP 音声デー

タ ストリーム内でインバンドで送信するか、またはMGCP または H323 シグナリング内で送信できま

す。DTMF リレーの詳細については、IOS ゲートウェイのドキュメントを参照してください。

PSTN ゲートウェイ アクセス：VPN 間

図 61 PSTN ゲートウェイ アクセス（VPN 間）

Cisco UnifiedCommunications

Manager

UnityM

VRF1 VRF2

CiscoIP

PSTNGW

IP Communicator

IP

2

3 1

PSTN 4

2262

99

114ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

サービス エッジ：まとめ

VPN 間のケースは、先に説明した VPN 内のケースとよく似ています。唯一の違いは、PSTN ゲート

ウェイと IP 電話間の RTP 音声メディアが、サービス エッジのファイアウォールを通過しなければなら

ないことです。CUCM とゲートウェイと IP 電話との間のシグナリングのインスペクションにより、

RTP メディア ストリームが使用する IP アドレスと UDP ポートに対して、ファイアウォールがピン

ホールを開きます。

PSTN ゲートウェイで必要なフィルタ

IP ネットワークからのコールでは、これらのフィルタが必要となります。パケットは、ファイア

ウォールの内部インターフェイスではフィルタリングされないため、MGCP または H323 フィルタリ

ングが CUCM から PSTN ゲートウェイのファイアウォールを通します。送信セッションでの返信トラ

フィックは、ファイアウォールによって自動的に許可されます。

PSTN からのコールでは、PSTN ゲートウェイが属する VPN の外部インターフェイスに、MGCP また

は H323 シグナリングのフィルタを明示的に追加する必要があります。次の設定例で、必要なフィルタ

が強調表示されています。

• MGCP ゲートウェイ

! MGCP inspection is not enabled by default and needs to be turned onpolicy-map global_policy class inspection_default inspect mgcp!name 10.13.100.20 CUCM_pub description CUCM publisher ! access-list outside-vrf2-ACL remark MGCP access-list outside-vrf2-ACL extended permit tcp any host CUCM_pub eq 2428 access-list outside-vrf2-ACL extended permit udp any host CUCM_pub eq 2427

• H323 ゲートウェイ

name 10.13.100.20 CUCM_pub description CUCM publisher ! access-list outside-vrf2-ACL remark H323 access-list outside-vrf2-ACL extended permit tcp any host CUCM_pub eq h323

PSTN の概要

このセクションでは、仮想ネットワークにおける MGCP ゲートウェイと H323 ゲートウェイの使用方

法について説明します。この設計では、ゲートウェイを IP テレフォニー エンドポイントに特化させて

おり、したがってゲートウェイを IP テレフォニー VPN に配置しています。これには、物理 IP 電話か

らの PSTN トラフィックを、サービス エッジとフュージョン ルータを経由してルーティングする必要

がないという効果があります。

SIP PSTN ゲートウェイはテストされていませんが、SIP PSTN ゲートウェイに接続されている VPN の外部ファイアウォール インターフェイスで SIP シグナリングが許可されている限り、このゲートウェ

イは機能するはずです。

PSTN ゲートウェイからのコールを受信するのに必要なフィルタが提供されています。

サービス エッジ：まとめネットワーク バーチャライゼーションのプロセス全体におけるサービス エッジが占める部分では、ポ

リシー実施およびトラフィック操作の大部分が行われます。このドキュメントの目的は、この目的を達

成するために展開されるさまざまな方法論に関する設計上のガイダンスを提供することです。

115ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

Cisco Validated Design

ドキュメントの 初のセクションで、次の 2 つのシナリオを区別して、共有サービスのコンセプトを定

義しました。

• さまざまな VRF ルーティング テーブル間でルート漏出を行うことで実現される、保護されていな

いサービス アクセス

• 推奨アプローチを表す保護されたサービス アクセスで、通常は定義されたフロントエンドとして

の仮想ネットワークとセキュリティ サービス（ファイアウォールまたはファイアウォール コンテ

キスト）によって展開される

保護されたサービス アクセスの特定のシナリオについては、2 つの配置モデル（シングル ティアと

デュアル ティア）を紹介し、その実装に必要な設計原則と設定手順について詳細に説明し、さまざま

な障害シナリオのもとでのコンバージェンス分析についても詳しく説明しました。

後に、サービス エッジ展開の特殊なアプリケーションとして、音声アプリケーションの仮想ネット

ワーク環境への統合の問題について、可能な技術的ソリューションについて説明しました。このソ

リューションの範囲は、現在キャンパス展開に限定されており、ネットワーク内の共有サービスの概念

を利用して、UC サービス（Cisco Call Manager、TFTP サーバなど）を配置します。仮想ネットワー

クが別々に分かれている状況で配置されているネットワーク エンティティ（IP 電話、PC など）は、こ

れらのサービスにアクセスする必要があります。

Cisco Validated DesignCisco Validated Design（シスコ検証済みデザイン）プログラムは、より高速で信頼性の高い、予測可

能な顧客展開を可能にするために設計され、テストされ、文書化されたシステムとソリューションで

す。詳細については、次の URL を参照してください。www.cisco.com/go/validateddesigns

このマニュアルに記載されているデザイン、仕様、表現、情報、および推奨事項（総称して「デザイ

ン」）は、障害も含めて本マニュアル作成時点のものです。シスコシステムズおよびそのサプライヤは、

商品性の保証、特定目的への準拠の保証、および権利を侵害しないことに関する保証、あるいは取引過

程、使用、取引慣行によって発生する保証をはじめとする、一切の保証の責任を負わないものとしま

す。いかなる場合においても、シスコシステムズおよびそのサプライヤは、このデザインの使用または

使用できないことによって発生する利益の損失やデータの損傷をはじめとする、間接的、派生的、偶発

的、あるいは特殊な損害について、あらゆる可能性がシスコシステムズまたはそのサプライヤに知らさ

れていても、それらに対する責任を一切負わないものとします。

デザインは予告なしに変更されることがあります。このマニュアルに記載されているデザインの使用

は、すべてユーザ側の責任になります。これらのデザインは、シスコシステムズ、そのサプライヤ、

パートナーの技術的な助言や他の専門的な助言に相当するものではありません。ユーザは、デザインを

実装する前に技術アドバイザーに相談してください。シスコによるテストの対象外となった要因によっ

て、結果が異なることがあります。

CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

116ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

Cisco Validated Design

All other trademarks mentioned in this document or Website are the property of their respective owners.The use of the word partner does not imply a partnership relationship between Cisco and any other company.(0807R) © 2007 Cisco Systems, Inc. All rights reserved.

Copyright © 2009, シスコシステムズ合同会社 . All rights reserved.

お問い合わせは、購入された各代理店へご連絡ください。

117ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J

Cisco Validated Design

118ネットワーク バーチャライゼージョン - サービス エッジ デザイン ガイド

OL-13637-01-J