Virtual Connect 使用雙層頭端架構，其中路由和 GRE 控制平面由一個裝置提供，而IPSec控制平面由另一個裝置提供。

完成後虛擬連線連線，將在客戶的企業網路與專用實例 Cisco 的資料中心之間建立兩個 GRE over IPSec通道。 對應區域內的每個冗餘資料中心。 合作夥伴或客戶透過 Control Hub 虛擬連線啟動表將對等所需的其他網路元素交換給Cisco 。

圖 1 顯示了用戶端的兩個集中器選項的 Virtual Connect部署模型的一個範例。

Virtual Connect - VPN是 Hub 設計，其中客戶的 Hub 網站會連線至特定地區內專用實例的資料中心的 DC1 和 DC2。

建議使用兩個 Hub 網站以獲得更好的備援，但具有兩個通道的一個 Hub 網站也是受支援的部署模型。

每個通道的頻寬限制為 250 Mbps。

同一地區內的客戶的遠端網站將需要透過客戶的 WAN 回連線至 Hub 網站，Cisco 不負責該連線。

合作夥伴應與客戶緊密合作，確保為「Virtual Connect」服務區域選擇最佳路徑。

圖 2 顯示了專用實例雲端連線對等互連區域。

Virtual Connect附加元件的路由是使用外部 BGP (eBGP) 在專用實例與客戶內部裝置 (CPE) 之間實施的。 Cisco將某個地區內每個冗餘 DC 的各自網路通告客戶的 CPE，而 CPE 必須將預設路由通告給Cisco。

• Cisco維護並指定

  • 通道介面IP位址（路由的暫時鏈結） Cisco從指定的共用位址空間（非公開可路由）指派

  • 隧道傳輸目的地位址（Cisco 端）

  • 客戶 BGP 路由設定的私人自治系統號碼 (ASN)

    • Cisco從指定的私人使用範圍指派： 64512 到 65534

• 用於在專用實例與 CPE 之間交換路由的 eBGP

  • Cisco會將指定的 /24 網路分成 2 個 /25 網路，以供各自地區中的每個 DC 使用。

  • 在 Virtual Connect 中，每個 /25 網路都由Cisco透過各自的點對點VPN通道（暫時鏈結）通告回 CPE

  • 必須使用相應的 eBGP 鄰居來配置 CPE。 若使用一個 CPE，將使用兩個 eBGP 鄰居，一個指向每個遠端通道。 若使用兩個 CPE，則每個 CPE 將有一個 eBGP 鄰居橋接至該 CPE 的單一遠端通道。

  • 每個 GRE 通道的Cisco端（通道介面IP）在 CPE 上設定為 BGP 鄰居

  • 需要 CPE 透過每個通道通告預設路由

  • CPE 負責根據需要在客戶的企業網路中重新分發已知的路由。

• 在非故障鏈結的情況下，單個 CPE 將具有兩個作用中/作用中通道。 對於兩個 CPE 節點，每個 CPE 將有一個作用中的通道，且兩個 CPE 節點都應處於作用中且正在傳遞流量。 在非故障情況下，流量必須分成兩條通道，前往正確的 /25 目的地，如果其中一個通道發生故障，則另一條通道可承載兩者的流量。 在此類故障情況下，當 /25 網路關閉時，/24 網路會用作備份路由。 Cisco將透過其內部 WAN 將客戶流量傳送至失去連線的 DC。

IPsec 通道交涉涉及兩個階段，即 IKEv2 階段和 IPsec 階段。 如果 IKEv2 階段協商未完成，則不會起始第二個 IPsec 階段。 首先，在第三方裝置上發出指令「showcrypto ikev2 sa」（在Cisco裝置上）或類似的指令，以驗證 IKEv2 階段作業是否處於作用中。 如果 IKEv2 階段作業處於非作用狀態，潛在原因可能是：

• 感興趣的流量不會觸發 IPsec 通道。

• IPsec 通道存取清單設定錯誤。

• 客戶與專用實例 IPsec 通道端點IP之間沒有連線。

• 專用實例端與用戶端之間的 IKEv2 階段作業參數不相符。

• 防火牆已封鎖 IKEv2 UDP封包。

首先，檢查 IPsec 記錄中是否有顯示 IKEv2 通道交涉進度的訊息。 記錄可能會指出 IKEv2 協商發生問題的位置。 缺少記錄訊息也可能指出未啟動 IKEv2 階段作業。

IKEv2 協商的一些常見錯誤是：

• CPE 端的 IKEv2 設定與Cisco端不相符，請重新檢查提及的設定：

  • 檢查 IKE 版本是否為版本 2。

  • 驗證加密和驗證參數是否符合專用實例端的預期加密。

    當使用「GCM」密碼時，GCM 通訊協定會處理驗證，並將驗證參數設定為 NULL。

  • 驗證生命週期設定。

  • 驗證 Diffie Hellman 模數群組。

  • 驗證偽隨機函數設定。

• 加密對應的存取清單未設定為：

  • 允許 GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255 (或等效指令)

    存取清單必須專門用於「GRE」通訊協定，而且「IP」通訊協定不起作用。

如果記錄檔訊息未顯示 IKEv2 階段的任何交涉活動，則可能需要進行封包擷取。

專用實例端可能並不總是開始 IKEv2 交換，有時可能期望客戶 CPE 端成為發起方。 檢查 CPE 端設定是否符合 IKEv2 階段作業起始的以下先決條件： 檢查從 CPE 通道傳輸IP到專用實例通道傳輸IP的 GRE 流量（通訊協定 50）的 IPsec 加密存取清單。 確保為 GRE 保持啟用了 GRE 通道介面，如果裝置不支援 GRE 保持不中斷，則會通知Cisco ，因為預設情況下將在專用實例端啟用 GRE 保持不中斷。 確保已啟用並使用專用實例通道IP的鄰居位址來設定 BGP。

如果設定正確，則以下開始 IPsec 通道和第一階段 IKEv2 交涉：

• 從 CPE 端 GRE 通道介面到專用實例端 GRE 通道介面的 GRE Keepalive。

• BGP 鄰居TCP階段作業從 CPE 端 BGP 鄰居到專用實例端 BGP 鄰居。

• 從 CPE 端通道IP 位址ping 專用實例端通道IP 位址。

  Ping 不能是通道傳輸IP至通道傳輸IP，而必須是通道IP至通道IP。

如果 IKEv2 流量需要封包追踪，請針對UDP和連接埠 500（如果沒有 NAT 裝置位於 IPsec 端點中間）或連接埠 4500（當端點）。

驗證是否有使用埠 500 或 4500 的 IKEv2 UDP封包透過 DI IPsec IP 位址傳送和接收。

專用實例資料中心可能並不總是開始第一個 IKEv2 封包。 要求是 CPE 裝置能夠向專用實例端起始第一個 IKEv2 封包。 如果本機防火牆允許，則還嘗試 ping 遠端 IPsec 位址。 如果從本端到遠端 IPsec 位址 ping 不成功，則執行路徑追踪以協助確定遺失封包的位置。 部分防火牆和網際網路設備可能不允許追踪路由。

在對 IPsec 第二階段進行疑難排解之前，請驗證 IPsec 第一階段（即 IKEv2 安全關聯）是否處於作用中。 執行「showcrypto ikev2 sa」或等效指令來驗證 IKEv2 階段作業。 在輸出中，驗證 IKEv2 階段作業是否已持續幾秒以上，並且沒有來回跳。 階段作業正常運行時間在輸出中顯示為階段作業「活動時間」或相當的值。

當 IKEv2 階段作業驗證為啟動且處於活動狀態後，調查 IPsec 階段作業。 與 IKEv2 階段作業一樣，請執行「showcrypto ipsec sa」或等效指令來驗證 IPsec 階段作業。 IKEv2 階段作業和 IPsec 階段作業必須都處於作用中，然後才能建立 GRE 通道。 如果 IPsec 階段作業未顯示為作用中，請檢查 IPsec 記錄以查看錯誤訊息或協商錯誤。

在 IPsec 協商期間可能遇到的一些較常見的問題是：

CPE 端的設定與專用實例端不相符，請重新檢查設定：

• 驗證加密和驗證參數是否符合專用實例端的設定。

• 驗證完美正向保密設定以及專用實例端的設定是否相符。

• 驗證生命週期設定。

• 驗證是否已將 IPsec 設定為通道模式。

• 驗證來源和目標 IPsec 位址。

當 IPsec 和 IKEv2 階段作業驗證為正常運作且處於活動狀態時，GRE 通道保持不中斷封包能夠在專用實例與 CPE 通道端點之間流動。 如果通道介面未顯示狀態，則有一些常見問題：

• 通道介面傳輸 VRF 與回送介面的 VRF 不相符（如果在通道介面上使用 VRF 組態）。

  若通道介面未使用 VRF 組態，則可以忽略此檢查。

• CPE 側通道介面未啟用 Keepalive

  如果 CPE 設備不支援保持不中斷，則必須通知Cisco ，以便也停用專用實例端的預設保持不中斷。 如果支援保持不中斷，請驗證是否已啟用保持不中斷。

• 通道介面的遮罩或IP 位址不正確，與專用實例預期的值不相符。

• 源或目標通道傳輸位址不正確，與專用實例的預期值不相符。

• 防火牆已封鎖 GRE 封包傳送至 IPsec 通道或從 IPsec 通道接收（GRE 通道透過 IPsec 通道傳輸）

Ping 測試應驗證本機通道介面是否正常運作，以及與遠端通道介面的連線是否良好。 執行從通道IP （不是傳輸IP）到遠端通道IP的 ping 檢查。

承載 GRE 通道流量的 IPsec 通道的加密存取清單僅允許 GRE 封包交叉。 因此，從通道傳輸IP到遠端通道傳輸IP的 ping 不起作用。

Ping 檢查會產生從來源通道傳輸IP到目標通道傳輸IP的 GRE 封包，而 GRE 封包的有效負載（內部IP）將是來源和目標通道IP。

如果 ping 測試不成功且驗證了上述項目，則可能需要進行封包擷取，以確保 icmp ping 產生 GRE 封包，然後將其封裝成 IPsec 封包，然後從來源 IPsec 位址傳送到目的地 IPsec 位址。 GRE 通道介面的計數器和 IPsec 階段作業計數器也可以協助顯示。是否傳送及接收封包正在增加。

除了 ping 流量之外，擷取還應顯示保持不中斷 GRE 封包，即使在流量閒置期間也是如此。 最後，如果設定了 BGP，則 BGP 保持不中斷封包也應作為封裝在 IPSEC 封包中的 GRE 封包以及透過VPN傳送。

在專用實例端，會啟用兩個功能，針對較大的封包大小動態調整 MTU。 GRE 通道會為流經VPN階段作業的IP封包新增更多標頭。 IPsec 通道在 GRE 標頭之上新增其他標頭將進一步降低通道允許的最大 MTU。

GRE 通道調整 MSS 功能，而 MTU 探索功能中的 GRE 通道路徑已在專用實例端啟用。 在用戶端設定「ip tcpadjust-mss 1350」或等效指令以及「通道路徑\u0002mtu-探索」或等效指令，以協助動態調整透過VPN通道的流量的 MTU。