紹介

Virtual Connect は、デュアルティア ヘッドエンド アーキテクチャを使用します。このアーキテクチャでは、1 つのデバイスによりルーティングおよび Gmail コントロール プレーンが提供され、 IPSecコントロール プレーンが別のデバイスによって提供されます。

ミーティングが完了したら、バーチャルコネクト接続の場合、お客様の企業ネットワークと専用インスタンスである Cisco のデータセンター間に 2 つのIPSecトンネル経由の 2 つのGRE が作成されます。 各リージョン内の各冗長データセンターに 1 つ。 ピアリングに必要な追加ネットワーク要素は、コントロール ハブバーチャルコネクトアクティベーション フォームを介して、パートナーまたは顧客によりCiscoに交換されます。

図 1 は、顧客側の 2 台のコンセントレータオプションの Virtual Connect の展開モデルの例を示しています。

仮想接続 - VPNはハブ設計であり、顧客のハブサイトは特定地域内の専用インスタンスのデータセンターの DC1 および DC2 に接続されます。

より良い冗長性のためには 2 つのハブ サイトが推奨されますが、2 つのトンネルを持つ 1 つのハブ サイトもサポートされている展開モデルです。

トンネルごとの帯域幅は 250 Mbps に制限されています。

同じ地域内の顧客のリモート サイトは、顧客の WAN を経由して Hub サイトに接続する必要がありますが、その接続に対する Cisco の責任はありません。

パートナーは顧客と緊密に連携し、「バーチャル コネクト」サービス地域に最も適したパスが選択されるようにすることが求められます。

図 2 は、専用インスタンス のクラウド接続ピアリング地域を示しています。

Virtual Connect アドオンのルーティングは、専用インスタンスと顧客のオンプレミス機器 (CPE) の間で外部 BGP (eBGP) を使用して実装されます。 Ciscoは、領域内の各冗長 DC のそれぞれのネットワークを顧客の CPE に通知し、CPE はデフォルト ルートをCiscoに通知する必要があります。

• Ciscoは、

  • トンネル インターフェイスのIPCisco（ルーティング用の一時的なリンク）で、指定された共有アドレススペースから（パブリックにルーティングされない）

  • トンネルトランスポート宛先アドレス（シスコ側）

  • 顧客 BGP ルーティング構成のプライベート自律システム番号 (ASN)

    • Ciscoは指定された私使用範囲から次を割り当てます。 64512 ～ 65534

• 専用インスタンスと CPE 間のルート交換に使用される eBGP

  • Ciscoは、割り当てられた /24 ネットワークを、それぞれの地域の DC ごとに 2 /25 に分割します

  • Virtual Connectでは、各 /25 ネットワークは、それぞれのポイント間VPNトンネル（一時的リンク）経由でCiscoによって CPE に戻されます。

  • CPE は適切な eBGP ネイバーで設定されている必要があります。 CPE を 1 つ使用する場合、2 つの eBGP ネイバーが使用され、1 つは各リモート トンネルをポイントします。 2 つの CPE を使用している場合、各 CPE には、その CPE の単一のリモート トンネルに接続する 1 つの eBGP ネイバーがあります。

  • 各GREトンネルのCisco側(トンネルインターフェイスIP)は、CPEでBGPネイバーとして設定されます

  • CPEは、各トンネル上のデフォルトルートを通知するために必要です

  • CPE は、必要に応じて、顧客の企業ネットワーク内で学習したルートを再配布する責任を負います。

• 非障害リンク障害状態では、単一の CPE に 2 つのアクティブ/アクティブトンネルがあります。 2 つの CPE ノードの場合、各 CPE には 1 つのアクティブなトンネルがあり、両方の CPE ノードがアクティブでトラフィックを渡す必要があります。 障害が発生しない場合のシナリオでは、トラフィックは正しい /25 の宛先に送られる 2 つのトンネルで分割される必要があり、トンネルの 1 つがダウンした場合でも、残りのトンネルが両方のトラフィックを伝送することができます。 このような障害シナリオでは、/25 ネットワークがダウンすると、/24 ネットワークがバックアップルートとして使用されます。 Ciscoは、内部 WAN を介して、接続を失った DC に向けて顧客トラフィックを送信します。

IPsec トンネル ネゴシエーションには、IKEv2 フェーズと IPsec フェーズの 2 つのフェーズがあります。 IKEv2 フェーズのネゴシエーションが完了しない場合、2 番目の IPsec フェーズは開始されません。 最初に、コマンド「show crypto IKEv2 sa」( Ciscoの装置) またはサードパーティの装置で同様のコマンドを発行して、IKEv2 セッションがアクティブであるかどうかを確認します。 IKEv2 セッションがアクティブでない場合、次の理由が考えられます。

• 対象トラフィックが IPsec トンネルをトリガーしません。

• IPsec トンネル アクセス リストの設定に誤りがあります。

• 顧客と専用インスタンス IPsec トンネル エンドポイントIPの間に接続がありません。

• IKEv2 セッション パラメータが、専用インスタンス側と顧客側で一致していません。

• ファイアウォールが IKEv2 UDPパケットをブロックしている。

最初に、IKEv2 トンネル ネゴシエーションの進行状況を示すメッセージの IPsec ログを確認します。 このログは、IKEv2 ネゴシエーションに問題がある場所を示す場合があります。 また、ロギング メッセージがない場合は、IKEv2 セッションがアクティブになっていないことを示す場合もあります。

ログ メッセージに IKEv2 フェーズのネゴシエーション アクティビティが表示されていない場合は、パケット キャプチャが必要になることがあります。

専用インスタンス側は常に IKEv2 交換を開始するとは限らず、顧客の CPE 側がイニシエーターになることを期待する場合があります。 IKEv2 セッション開始に向けて以下の前提条件について CPE 側の設定を確認します。 CPE トンネル転送IPから [専用インスタンストンネル転送IP] への、GRE トラフィック (プロトコル 50) の IPsec 暗号化アクセス リストを確認します。 機器がGREキープアライブをサポートしていない場合、GREキープアライブはデフォルトで専用インスタンス側で有効になるため、 Ciscoに通知されます。 BGP が有効になっており、専用インスタンス トンネルIPの近隣 アドレスで構成されていることを確認します。

正しく設定すると、IPsec トンネルと第 1 フェーズの IKEv2 ネゴシエーションが開始されます。

• CPE 側のGRE トンネル インターフェイスから専用インスタンス側のGRE トンネル インターフェイスへのGRE キープアライブ。

• CPE 側 BGP 近隣から専用インスタンス側 BGP 近隣への BGP 近隣TCPセッション。

• CPE 側のトンネルIPアドレスから、専用インスタンス側のトンネルIPアドレスへの ping 。

  Ping はトンネルトランスポートIPからトンネルトランスポート IP へはできず、トンネル IP からトンネルIPへのトンネルIPである必要がありIP。

IKEv2 トラフィックにパケット トレースが必要な場合は、 UDPに対して、ポート 500（IPsec エンドポイントの中央にある NAT デバイスがない場合）またはポート 4500（NAT デバイスが IPsec の中央に挿入されている場合）のいずれかのフィルタを設定します。エンドポイント)。

ポート 500 または 4500 の IKEv2 UDPパケットが DI IPsec IPアドレスとの間で送受信されることを確認します。

専用インスタンスのデータセンターは、常に最初の IKEv2 パケットを開始するとは限りません。 要件は、CPE デバイスが専用インスタンス側への最初の IKEv2 パケットを開始できることです。 ローカル ファイアウォールが許可している場合は、リモート IPsec アドレスへの ping も試行します。 ローカルからリモートの IPsec アドレスへの ping が成功しなかった場合は、ルートのトレースを実行し、パケットがドロップされた場所を特定します。 一部のファイアウォールとインターネット機器は、トレースルートを許可しない場合があります。

IPsec の第 2 フェーズのトラブルシューティングを行う前に、IPsec の第 1 フェーズ（つまり、IKEv2セキュリティアソシエーション）がアクティブであることを確認します。 「show crypto IKEv2 sa」または同等のコマンドを実行して、IKEv2 セッションを確認します。 出力で、IKEv2 セッションがアップ状態になってから数秒以上経過していること、およびバウンスされていないことを確認します。 セッションの稼働時間は、セッションの「アクティブ時間」または出力に同等に表示されます。

IKEv2 セッションがアップし、アクティブであることを確認したら、IPsec セッションを調査します。 IKEv2 セッションの場合と同様に、「show crypto ipsec sa」または同等のコマンドを実行して IPsec セッションを確認します。 IKEv2 セッションと IPsec セッションの両方が、GRE トンネルの確立前にアクティブになっている必要があります。 IPsec セッションがアクティブとして表示されていない場合は、IPsec ログでエラー メッセージやネゴシエーション エラーを確認してください。

IPsec ネゴシエーション中に発生する可能性がある、より一般的な問題には、次のようなものがあります。

CPE 側の設定が専用インスタンス側と一致しません。設定を再確認してください:

• [暗号化] および [認証] パラメータが専用インスタンス側の設定と一致することを確認します。

• Personal Forward Secrecy 設定を確認し、専用インスタンス側の設定と一致することを確認します。

• ライフタイム設定を確認します。

• トンネル モードで IPsec が設定されていることを確認してください。

• 送信元と宛先の IPSec アドレスを確認します。

IPsec および IKEv2 セッションが動作していてアクティブであることが確認されると、GRE トンネル キープアライブ パケットは、専用インスタンスと CPE トンネル エンドポイント間でフローすることができます。 トンネル インターフェイスがアップ ステータスで表示されない場合、いくつかの一般的な問題があります。

• トンネル インターフェイス転送 VRF は、ループバック インターフェイスの VRF と一致しません（VRF 設定がトンネル インターフェイスで使用されている場合）。

  VRF 設定がトンネル インターフェイスで使用されていない場合は、このチェックを無視することができます。

• CPE側のトンネル インターフェイスでキープアライブが有効になっていない

  キープアライブが CPE 機器でサポートされていない場合、専用インスタンス側のデフォルト キープアライブが無効になるようにCiscoに通知する必要があります。 キープアライブがサポートされている場合、キープアライブが有効であることを確認します。

• トンネル インターフェイスのマスクまたはIPアドレスが正しくなく、専用インスタンスで想定される値と一致しません。

• 送信元または接続先のトンネル転送アドレスが正しくなく、専用インスタンスの必要値と一致しません。

• ファイアウォールが、GRE パケットを IPsec トンネルへの送信、または IPsec トンネルからの受信からブロックしている（GRE トンネルは IPsec トンネル経由でトランスポートされます）

Ping テストでは, ローカル トンネル インターフェースが起動していること, およびリモート トンネル インターフェースへの接続が良好であることを確認する必要があります。 トンネルIP (トランスポートIPではなく) からリモートトンネルIPに対して ping チェックを実行します。

Gmail のトンネル トラフィックを伝送する IPsec トンネルの暗号アクセス リストでは、GRE パケットだけが許可されます。 その結果、トンネル転送IPからリモートのトンネル転送IPへの ping が機能しなくなります。

ping チェックの結果、ソース トンネルトランスポートIPから宛先トンネルトランスポートIPまで生成されたGRE パケットになり、GRE パケットのペイロード（内部IP）は送信元と宛先のトンネルIPになります。

ping テストに成功せずに、上記の項目が検証された場合は、icmp ping の結果として REST パケットに化された上で、GRE パケットを確認するためにパケット キャプチャが必要になることがあります。このパケットは、IPsec パケットにカプセル化されて、送信元 IPsec アドレスから次のアドレスに送信されます。接続先 IPSec アドレス。 Gmail トンネル インターフェイスと IPsec セッション カウンタのカウンタも、表示に役立ちます。送信パケットと受信パケットが増加している場合。

ping トラフィックに加えて、キャプチャではトラフィックがアイドル状態の場合でもキープアライブ Gmail のパケットが表示される必要があります。 最後に、BGP が設定されている場合、BGP キープアライブ パケットは、 VPN経由でも IPSEC パケットにカプセル化された Gmail として送信する必要があります。

専用インスタンス側では、大きなパケットの MTU サイズを動的に調整するための 2 つの機能が有効になっています。 Gmail トンネルは、 VPNセッションを通過するIPパケットにさらにヘッダーを追加します。 IPsec トンネルは、GRE ヘッダーの上に追加のヘッダーを追加し、トンネル経由で許可される最大 MTU をさらに減らします。

GRE トンネルは MSS 機能を調整し、MTU 検出機能の Gmail トンネル パスは、専用インスタンス側で有効になっています。 カスタマー側で「ip tcp準備-mss 1350」または同等のコマンドを設定し、カスタマー側で「トンネルパス\u0002mtu-discovery」または同等のコマンドを設定すると、 VPNトンネル経由のトラフィックの MTU を動的に調整できます。