OL-13637-01-J warning

ネットワークバーチャライゼージョン - サービスエッジデザインガイド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/）をご確認ください。

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

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

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

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

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

www.cisco.com/jp/go/safety_warning/

http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/GuestAcc.html


http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/NACDepl.html


http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/PathIsol.html


概要

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

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

意味します（図 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


OL-13637-01-J

http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/AccContr.html



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

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

ネットワークを作成できます。これらの仮想ネットワーク（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


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 は、上記の概念図を示します。


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


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


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 を参照）。


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


OL-13637-01-J


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

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

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

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

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

PC Red PC Green

IGPIGP

BGP

2262

48


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


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


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 デバイス上でも定義され

たとします。


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


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


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


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


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


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 を参照）について説明する場合、デザインに関す

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

す。


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


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


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


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）を利用できるようにするために、この小限のリリースの使用が必要になります。


OL-13637-01-J

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


（注） 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


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


.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


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


OL-13637-01-J

http://www.cisco.com/en/US/netsol/ns743/networking_solutions_program_home.html



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


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


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


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


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


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 に示します。


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


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


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


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


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


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


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 と共有サービスエリア間の光ファイバの障害）


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

時間が生じます。

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

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

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

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

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

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


OL-13637-01-J


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

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

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

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

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

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

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

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

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

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

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

い。

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



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

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


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

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


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


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


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 が定義されます。このピアリングは、特定の障害シナリオにおいて、共有サービ

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

ります。






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

（これは、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


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 コンバージェンスの結果






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


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


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 つの主要なコンポーネント：

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

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

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

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

断時間は 4 ～ 5 秒になります。OSPF の隣接関係がリセットされないようにするには、OSPF タイマーのアグレッシブ設定を低めにできます。これにより、OSPF の不感時間が、トラ

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

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




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






復旧時間は、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


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


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


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 セッションも確立されていま

す。この後者のピアリングは、特定の障害シナリオにおいて、共有サービスからキャンパスコア

に向けてトラフィックを再ルーティングする場合に使用される可能性があります。






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

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


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


OL-13637-01-J


前述のように、D1 と D2 は、それらのルーティングテーブルの中に S1 内のフュージョンルータから

受信したデフォルトルートをインストールします。結果的なトラフィックフローを図 17 に示します。

eBGP コンバージェンス結果








この値は、フュージョンルータが 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）へのルートが削除されま

す。














OL-13637-01-J


上記のトラフィックの中断時間は、S2 内のファイアウォールがアクティブな役割を担うようにな

るまでに必要な時間が原因です。これは現在、FWSM の配置では 3 秒未満に設定できません。



この中断時間は、すべてのフローに影響を及ぼし、ディストリビューション VRF が S1 内の

フュージョンルータに障害が発生したことを認識するまで、そのルータにトラフィックを送信し

続けるために起こります。この状態は、上記の値に復旧時間を設定する BGP の保持時間の期限切

れによってだけ表されます。


S1 に障害が発生すると、S1 にトラフィックを配信するのにレイヤ 2 パスは利用できなくなるの

で、共有サービスエリアからのフロー（D1 内の VRF 宛てのフロー）の半分は、9 ～ 10 秒間中断

されます。フローの残り半分は、D2 内の VRF に送信され、S2 内の FWSM がアクティブになるの

に必要な時間によって、およそ 3 ～ 4 秒間だけ中断されます。






復旧時間は、ここでも BGP 保持時間に依存します。S1 上のフュージョンルータ（アクティブな HSRP デバイス）が、eBGP ピアリングを削除するまで障害の発生したスイッチ内の VRF へトラ

フィックを送信し続けるためです。

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

ファイアウォールコンテキストをルーテッドモードで配置する場合、コンテキストに関するルーティ

ングプロトコルがサポートされていないということが、現在の制限事項です（Cisco ファイアウォール

では、仮想かされていない場合（つまり、シングルコンテキストモード）だけ、ルーテッドモードで

のルーティングプロトコルをサポートします）。このマニュアルとの関連で推奨される方法としては、

図 24 に示すように、eBGP を利用してフュージョンルータとディストリビューションレイヤで定義さ

れているさまざまな VRF 間でルーティング情報を交換できるようにする方法が挙げられます。


OL-13637-01-J


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

（注）代わりの方法としては、VRF、ファイアウォールコンテキスト、およびフュージョンルータ間で単純

に静的ルーティングを使用する方法が挙げられます。この方法は、特定のシナリオ、特に冗長サイトに

サービスエッジ機能を配置する場合は、トラフィックがブラックホールに入ってしまう可能性がある

ので推奨されません。

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

ルを図 25 に示します。

RedVPN

GreenVPN

YellowVPN

L3L3 L3

eBGP

2262

65


OL-13637-01-J


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

トランスペアレントモードによるファイアウォールコンテキストの配置との関連で、このネットワー

クトポロジを図 14 のトポロジと比較する場合は、次のことに注意してください。

• 各ファイアウォールコンテキストは、ネットワーク内でルーテッドホップになります。これは、

VLAN の内部および外部のファイアウォールが異なる 2 つの IP サブネットに属するようになるこ

とを意味します。

• 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.113.0/24 VLAN 904 10.136.114.0/24

VLAN 1054 10.136.104.0/24VLAN 1053 10.136.103.0/24



.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


OL-13637-01-J


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

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

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

ます）。

• 透過的なファイアウォールの配置の場合、フュージョンルータによって、インターフェイス（ま

たは SVI）が各キャンパス VPN 専用になるように定義されます。

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

適切に配置されている場合には（eBGP に必要な設定は、このマニュアルのプロトコル特有のセクショ

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


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

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

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

D2D1SiSi L3

L2

L2 L2

L2 L2

Red VPN

S2S1

2262

56


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


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


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


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


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


OL-13637-01-J


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

トラフィックフローおよびルーティングピアリングの観点からは、このシナリオは光ファイバ障害の

シナリオと非常に似ています。

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

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

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

ルーティングです。

• サービスからコアへのフロー：S1 内部のファイアウォールは、すべてのトラフィックフローをサ

ブネット（VLAN 1053）外のファイアウォール上の HSRP VIP に送信し続けます。HSRP がアク

ティブになると、これらすべてのフローが D2 の VRF によってピックアップされます。停止の長

さは、このプロセスでかかる時間によって異なります。タイマーをサブセカンドに設定すると、こ

のコンバージェンスイベントがサブセカンド以内に収まります。

次のセクションでは、これまでに説明してきたすべての障害シナリオのコンバージェンス結果を含む、

eBGP の配置に関する特定の設計と設定上の考慮事項について説明します。


ルーテッドモードでファイアウォールコンテキストを配置するときに配信スイッチ（D1 および D2）とフュージョンルータで定義される VRF 間でのピアリングで BGP を使用する場合の考慮事項は、ト

ランスペアレントモードのファイアウォールですでに行ったものと基本的に同じです（詳細について

は、対応するセクションを参照してください）。唯一の違いは、S1 では、経路の決定がファイアウォー

ルの内部サブネット（VLAN 903）上のアクティブな HSRP デバイスに基づいてルーテッドファイア

ウォールによって行われるため、フュージョンルータが適なデフォルト経路を確実にアドバタイズ

するための要件が存在しないことです。

eBGP コンバージェンス結果

さまざまな障害シナリオで実現される収束結果を以下にまとめます。


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


OL-13637-01-J







この値は、D2 上の VRF がサブネット（VLAN 1053）外のファイアウォールで HSRP をアクティ

ブできる早さによって決定されます。サブセカンドの HSRP タイマーを設定すると、復旧時間が

サブセカンド以内に収まります。














るまでに必要な時間が原因です。これは現在、FWSM の配置では 3 秒未満に設定できません。





るまでに必要な時間が原因です。ファイアウォールがトランスペアレントモードで使用される eBGP 構成とは異なり、設定されている BGP のホールドタイムは、このケースで実現されるコン

バージェンス時間を決定する要素とはなりません。これは、ファイアウォールコンテキストがこ

こではホップにルートされており、常にサブネット内とサブネット外の両方のファイアウォールに

トラフィックを送信するためです。






この停止は、D2 の VRF がサブネット（VLAN 1053）外のファイアウォールでアクティブな HSRP デバイスとなるのに必要な時間によって決定されます。繰り返しになりますが、HSRP タイ

マーをサブセカンドにして使用する場合は、停止時間にサブセカンド値を入力できます。


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 秒


OL-13637-01-J


– ファイアウォールの障害：このケースでコンバージェンスを決定する主要な要素は、ファイア

ウォールのホールドタイムです。現在、FWSM で設定可能な小値は 3 秒ですが、将来のリ

リースではこれが改善される可能性があります。

– サービススイッチの障害：ファイアウォールのホールドタイムもこのケースでコンバージェ

ンスに影響する主要な要素で、ここでも上記と同じ配慮がなされています。さらに、冗長化電

源の導入、スーパーバイザ機能の冗長化などにより、特定のデバイスの復元力を向上させるこ

とも可能です。

• IGP（EIGRP または OSPF）を、トランスペアレントモードのファイアウォールと併用すること

も推奨します。上記で行ったのと同様の考慮事項をここでも繰り返します。さらに、いくつかの障

害シナリオ（EIGRP でのテスト 1 および EIGRP と OSPF でのテスト 4）での復旧時間は、設定さ

れた IGP ホールドタイムによって決定されます。全体的な設計の安定性のためには、サブセカン

ド IGP タイマーを使用することは好ましくないため、この復旧時間を短縮する手段は限られてい

ます。

シングルティアの実装

保護されたサービスアクセスを配置するための 2 番目のモデルでは、図 33 に示すようなシングルティ

アの実装が必要となります。


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


OL-13637-01-J


（注）デフォルトの VRF（aka グローバルテーブル）も、フュージョンルーティング機能を実行す

るのに使用できます。

• フュージョン VRF は、レイヤ 3 接続のピアとして機能します。この機能は、サービススイッチを

接続するレイヤ 2 ポートチャネルトランクに引き継がれる特定の VLAN を、この目的で指定する

ことで実現できます。

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

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

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

り、外部インターフェイスは VRF 側になっています。この選択は、共有エリア内に配置された

サービスを保護するための要件によって決まります。

• VLAN の内部と外部のファイアウォールが、スイッチと HSRP 間に拡張されて、両方のサブネッ

トでデフォルトゲートウェイ機能を提供するのに使用されます。

次のセクションでは、シングルティアサービスエッジモデルを配置するための、設計上の考慮事項と

設定ガイドラインに重点を置いて説明します。2 ティア配置ですでに説明したシナリオと設定がよく似

ているため、重要な違いだけを取り上げて説明します。

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

2 ティアモデルの説明ですでに述べたように、ファイアウォールコンテキストをトランスペアレントモードで配置することで、すでに使用されている IP アドレスを変更することなく、ファイアウォール

をネットワークに挿入できるようになります。さらに、図 34 に示すように、下部で定義されている VRF と上部のフュージョンルータの間で、さまざまなタイプのルーティングピアリングを確立でき

ます。


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


OL-13637-01-J



設定例はすべて図 36 のネットワークトポロジ、特に Red VPN を参照しています。

L2

L2 L2

Red VPN

S2/D2S1/D1

2262

74


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



.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


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


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


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


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 を利用して、ファイアウォールコンテキスト全体でルーティングピアリングを確立するという興味深

い課題がもたらされます。

eBGP をシングルボックスシナリオで機能させるには、次の 2 つの具体的な機能が必要となります。

• VRF アドレスファミリごとに個別の BGP ルータ ID を提供する。


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


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


OL-13637-01-J

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html


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 が推奨されます。


OL-13637-01-J


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

シングルティアシナリオでの対応するお勧めの配置モデルを図 38 に示します。

RedVPN

GreenVPN

YellowVPN

L3L3 L3

eBGP

2262

65


OL-13637-01-J


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

図 38 から次の考慮事項が導かれます。

• 各ファイアウォールコンテキストは、ネットワーク内でルーテッドホップになります。これは、

VLAN の内部および外部のファイアウォールが異なる 2 つの IP サブネットに属するようになるこ

とを意味します。

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

イ機能を提供するのに利用されます。





• フュージョン 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



.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


OL-13637-01-J


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

適切に配置されている場合には（eBGP に必要な設定は、このマニュアルのプロトコル特有のセクショ

ンで後ほど説明されます）、図 35 に示すように、各 VRF が両方のフュージョン 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


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


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 のファイアウォー

ルを示していますが、共有サービス設計は、このマニュアルの前のセクションで説明したサイト内冗長


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


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


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 のサービスエッジを経由するデフォルトルートを常に探っています。


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


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


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


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 に示します。


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


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


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）間と仮想セグメント内で発生するアーキテク

チャが提供されています。


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 に再配信します。


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


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 への登録に必要となるシグナリングを示します。


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


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


Manager

TFTP DNSDHCP ADM

VRF1 VRF2

IP CommunicatorSoftphone

2 2

1

33

2262

85


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 間音声ストリーム


Manager

TFTP DNSDHCP ADM

VRF1 VRF2

CiscoIP

IP Communicator

IP

2 2

2

1

2262

86


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


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 では、この電話がビデオ対応であることを示すチェックボックスが設定されています。


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 フレームを受信できるようにしておく必要があります。


Manager

TFTP DNSDHCP ADM

CiscoIP

CDP CiscoUnified Video

Advantage

1

2

VRF1 VRF2

IP

2262

87


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


Manager

TFTP DNSDHCP ADM

VRF1 VRF2

2

1

Cisco Unified VideoAdvantage

2262

88


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 内に展開されているという特殊なケースを示してい

ます。


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


Manager

TFTP DNSDHCP ADM

VRF1 VRF2

Cisco Unified VideoAdvantage

1RTP

2UDP

2262

89


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 つの電話間にコールが

送信されると、電話は音声エンドポイントとしての役割を果たします。この場合は、データデバイス

がビデオエンドポイントを表します。


Manager

TFTP DNSDHCP ADM

VRF1 VRF2 VRF3

CiscoIP

1 2

IPIP

CUVA CUVA

UDPRTP

2262

90


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 がワークステーション上で起動されたときに発生するデータフローにつ

いて見ていきます。


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 のログイ


ManagerCiscoUnified

PresenceTFTP DNSDHCP AD

VRF1

1

23M

4

5

PersonalCommunicator

VRF2

2262

91


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 を制御してコールを実

行するときに発生するフローについて説明します。


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


Manager

TFTP DNSDHCP ADM

VRF1 VRF2

1


3

IP

2

2262

92


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


Manager

TFTP DNSDHCP AD

VRF1 VRF2

12a

3


IP

M2b

2262

93


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


Manager

TFTP DNSDHCP AD

VRF1 VRF2

1

3


IP

M2

4

2262

94


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 ユー

ザとリアルタイムでチャットできるようになり、時間の節約になり、不在による行き違いも少なくな

ります。


Manager

TFTP DNSDHCP AD

VRF1 VRF2

1

M

2

3

4



2262

95


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 トラフィックを許可します。


ManagerCiscoUnified

PresenceTFTP DNSDHCP AD

VRF1 VRF2

1

M

2



2262

96


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 と共に配置す

ることで、一貫性のあるコール制御と、すべての音声クライアントに対するメッセージングアクセス

が可能になります。


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 ポートについて、ファイアウォールは動的に開きます。そのトラフィックで使用するファイアウォールピンホールは、コールが終了すると動的に閉じられます。


Manager

UnityM

VRF1 VRF2

CiscoIP

IP Communicator

IP

2

3

1 1

2

2262

97


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 シグナ

リングを使用して、コールのセットアップを行います。


Manager

UnityM

VRF1 VRF2

CiscoIP

PSTNGW

IP Communicator

IP

2

3

1

PSTN 4

2262

98


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 間）


Manager

UnityM

VRF1 VRF2

CiscoIP

PSTNGW

IP Communicator

IP

2

3 1

PSTN 4

2262

99


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 ゲートウェイからのコールを受信するのに必要なフィルタが提供されています。

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

リシー実施およびトラフィック操作の大部分が行われます。このドキュメントの目的は、この目的を達

成するために展開されるさまざまな方法論に関する設計上のガイダンスを提供することです。


OL-13637-01-J


ドキュメントの初のセクションで、次の 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.


OL-13637-01-J

www.cisco.com/go/validateddesigns


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.

お問い合わせは、購入された各代理店へご連絡ください。


OL-13637-01-J



OL-13637-01-J

Documents

OL-13637-01-J warning