Virtual Connectは、ルーティングとGRE制御プレーンが1つのデバイスによって提供され、IPSec制御プレーンが別のデバイスによって提供される2層のヘッドエンドアーキテクチャを使用します。

Virtual Connect接続が完了すると、お客様のエンタープライズネットワークと専用インスタンスCiscoのデータセンターの間に2つのGRE over IPSecトンネルが作成されます。 各リージョン内の冗長データセンターに 1 つ。 ピアリングに必要な追加のネットワーキング要素は、Control Hub Virtual Connect アクティベーション フォーム経由でパートナーまたは顧客から Cisco に交換されます。

図1は、顧客側の2コンセントレータオプションのVirtual Connect展開モデルの例です。

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

冗長性を向上させるために 2 つの Hub サイトが推奨されますが、2 つのトンネルを備えた One Hub サイトもサポートされている展開モデルです。

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

同じ地域内のお客様のリモートサイトは、お客様の WAN 経由でハブサイトに接続する必要がありますが、その接続については Cisco の責任ではありません。

パートナーは、お客様と緊密に連携し、「バーチャルコネクト」サービス地域に最適なパスを選択することが期待されます。

図2は、専用インスタンスクラウド接続ピアリングリージョンです。

Virtual Connect アドオンのルーティングは、専用インスタンスと Customer Premise Equipment (CPE) の間の外部 BGP (eBGP) を使用して実装されます。 Cisco は、リージョン内の冗長な DC の各ネットワークを顧客の CPE にアドバタイズし、CPE は Cisco へのデフォルト ルートをアドバタイズする必要があります。

• Cisco の保守と割り当て

  • Cisco が指定された共有アドレス空間から割り当てるトンネルインターフェイス IP アドレッシング（ルーティングの一時的なリンク）（非公開ルーティング可能）

  • トンネル トランスポートの淡水化アドレス (Cisco 側)

  • 顧客 BGP ルーティング設定用のプライベート自律システム番号（ASN）

    • Cisco は、指定されたプライベート使用範囲から割り当てます。 64512から65534

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

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

  • 仮想接続では、各 /25 ネットワークは、それぞれのポイントツーポイント VPN トンネル（トランジェントリンク）を介して、シスコによって CPE にアドバタイズされます。

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

  • 各 GRE トンネルのシスコ側（トンネルインターフェイス IP）は、CPE の BGP ネイバーとして設定されます。

  • CPEは、各トンネルのデフォルトのルートを広告する必要があります。

  • CPEは、必要に応じて、cutomerのエンタープライズネットワーク内の学習ルートを再配布する責任があります。

• 非障害リンク障害状態では、1つのCPEに2つのアクティブ/アクティブトンネルがあります。 2 つの CPE ノードの場合、各 CPE には 1 つのアクティブなトンネルがあり、両方の CPE ノードはアクティブで、トラフィックを渡す必要があります。 失敗しないシナリオでは、トラフィックは正しい/25の目的地に行く2つのトンネルに分割する必要があります。 トンネルの1つがダウンすると、残りのトンネルは両方のトラフィックを運ぶことができます。 このような失敗シナリオでは、/25 ネットワークがダウンすると、/24 ネットワークがバックアップ ルートとして使用されます。 Cisco は、接続が失われた DC に対して、内部 WAN 経由で顧客のトラフィックを送信します。

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

• 興味深いトラフィックは、IPsecトンネルをトリガーしません。

• IPsec トンネル アクセス リストが間違っています。

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

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

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

まず、IKEv2 トンネルネゴシエーションの進行状況を示すメッセージについては、IPsec ログを確認してください。 ログは、IKEv2 ネゴシエーションに問題がある場所を示している可能性があります。 ログメッセージの欠如は、IKEv2 セッションがアクティブ化されていないことを示す場合があります。

IKEv2 ネゴシエーションのよくあるエラーは次のとおりです。

• CPE 側の IKEv2 の設定が Cisco 側と一致しません。次の設定を再確認してください。

  • IKE バージョンがバージョン 2 であることを確認します。

  • 暗号化と認証パラメータが、専用インスタンス側の予想される暗号化と一致していることを確認します。

    "GCM" 暗号が使用中の場合、GCM プロトコルは認証を処理し、認証パラメータを NULL に設定します。

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

  • Diffie Hellman係数群を検証する。

  • Pseudo Random Function の設定を確認します。

• 暗号マップのアクセスリストは、以下に設定されていません。

  • GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (または同等のコマンド) を許可

    アクセスリストは「GRE」プロトコル専用でなければならず、「IP」プロトコルは機能しません。

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

専用インスタンス側は常に IKEv2 取引所を開始するとは限らず、場合によっては顧客の CPE 側がイニシエーターになることを期待する場合があります。 IKEv2 セッション開始のための次の前提条件について、CPE 側の設定を確認します。 CPE トンネルトランスポート IP から専用インスタンストンネルトランスポート IP への GRE トラフィック（プロトコル 50）の IPsec 暗号アクセスリストを確認します。 GRE Keepalives が GRE Keepalives をサポートしていない場合は、GRE Tunnel インターフェイスが GRE Keepalives に対して有効になっていることを確認してください。GRE Keepalives はデフォルトで専用インスタンス側で有効になっているため、Cisco に通知されます。 BGP が専用インスタンス トンネル IP のネイバー アドレスで有効化され、設定されていることを確認します。

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

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

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

• CPE 側トンネル IP アドレスから専用インスタンス側トンネル IP アドレスに ping します。

  Ping は、トンネル輸送 IP へのトンネル輸送 IP にはできません。トンネル IP からトンネル IP にする必要があります。

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

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

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

IPsec 第 2 フェーズをトラブルシューティングする前に、IPsec 第 1 フェーズ（つまり、IKEv2 セキュリティ関連付け）がアクティブであることを確認します。 「show crypto ikev2 sa」または同等のコマンドを実行して、IKEv2 セッションを検証します。 出力では、IKEv2 セッションが数秒以上起動しており、バウンスしていないことを確認します。 セッションのアップタイムは、セッション "Active Time" または同等の出力として表示されます。

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

IPsec交渉中に遭遇する可能性のあるより一般的な問題のいくつかは次のとおりです。

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

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

• 完全転送秘密設定と、専用インスタンス側の一致設定を確認します。

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

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

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

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

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

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

• Keepalives は CPE 側トンネル インターフェイスでは有効になっていません

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

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

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

• ファイアウォールは、GRE パケットを IPsec トンネルに送信したり、IPsec トンネルから受信したりすることをブロックしています (GRE トンネルは IPsec トンネル経由で転送されます)。

ping テストでは、ローカル トンネル インターフェイスが起動し、リモート トンネル インターフェイスとの接続が良好であることを確認する必要があります。 リモート トンネル IP へのトンネル IP（トランスポート IP ではない）から ping チェックを実行します。

GRE トンネル トラフィックを運んでいる IPsec トンネルの暗号アクセス リストでは、GRE パケットのみがクロスできます。 その結果、トンネル輸送IPからリモートトンネル輸送IPへの接続は機能しません。

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

ping テストが成功せず、前の項目が検証された場合、icmp ping の結果として GRE パケットが生成され、それが IPsec パケットにカプセル化され、送信元 IPsec アドレスから宛先 IPsec アドレスに送信されるように、パケット キャプチャが必要になる場合があります。 GRE トンネル インターフェイスと IPsec セッション カウンタのカウンタも表示できます。

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

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

GRE トンネルは MSS 機能を調整し、MTU 検出機能の GRE トンネル パスは専用インスタンス側で有効になります。 「ip tcp adjust-mss 1350」または同等のコマンド、および「tunnel path\u0002mtu-discovery」または同等のコマンドを顧客側に設定して、VPNトンネルを介したトラフィックのMTUの動的調整を支援します。