Virtual Connect는 듀얼 계층 헤드엔드 아키텍처를 사용하며, 여기서 라우팅 및 GRE 제어 평면은 하나의 장치에서 제공되고 IPSec 제어 평면은 다른 장치에서 제공됩니다.

가상 연결 연결이 완료되면 고객의 엔터프라이즈 네트워크와 Cisco의 데이터 센터 전용 인스턴스 간에 IPSec을 통한 두 개의 GRE가 생성됩니다. 각 지역 내에 있는 각 중복 데이터센터에 하나씩 있습니다. 피어링에 필요한 추가 네트워킹 요소는 Control Hub 가상 연결 활성화 양식을 통해 파트너 또는 고객이 Cisco로 교환합니다.

그림 1은 고객 측의 2-집중 장치 옵션에 대한 가상 연결 배포 모델의 예를 보여줍니다.

가상 연결 - VPN은 Hub 디자인이며, 고객의 허브 사이트는 특정 지역 내에서 전용 인스턴스의 데이터센터의 DC1 및 DC2에 연결됩니다.

더 나은 중복을 위해 두 개의 허브 사이트가 권장되지만, 두 개의 터널이 있는 한 개의 허브 사이트도 지원되는 배포 모델입니다.

터널당 대역폭은 250Mbps로 제한됩니다.

동일한 지역 내의 고객의 원격 사이트는 고객의 WAN을 통해 Hub 사이트에 다시 연결해야 하며, 해당 연결에 대한 Cisco의 책임은 아닙니다.

파트너는 고객과 긴밀히 협력하여 'Virtual Connect' 서비스 지역에 대해 최적의 경로를 선택할 수 있도록 해야 합니다.

그림 2는 전용 인스턴스 클라우드 연결 피어링 지역을 표시합니다.

가상 연결 추가 기능을 위한 라우팅은 전용 인스턴스와 CPE(Customer Premise Equipment) 간에 외부 BGP(eBGP)를 사용하여 구현됩니다. Cisco는 지역 내의 각 중복 DC에 대해 해당 네트워크를 고객의 CPE로 광고하고 CPE는 Cisco로 기본 경로를 광고하는 데 필요합니다.

• Cisco 유지 관리 및 할당

  • 터널 인터페이스 IP 주소 지정(라우팅을 위한 임시 링크) 지정된 공유 주소 공간에서 Cisco 할당(비공개적으로 라우팅 가능)

  • 터널 전송 desitination 주소(Cisco 측)

  • 고객 BGP 라우팅 구성에 대한 개인 자율 시스템 번호(ASN)

    • Cisco는 지정된 비공개 사용 범위에서 지정합니다. 64512에서 65534까지

• 전용 인스턴스와 CPE 간의 경로 교환에 사용되는 eBGP

  • Cisco는 할당된 /24 네트워크를 각 지역의 각 DC에 대해 2 /25로 분할합니다.

  • Virtual Connect에서 각 /25 네트워크는 Cisco가 해당 지점 간 VPN 터널(임시 링크)을 통해 CPE로 다시 광고됩니다.

  • CPE는 적절한 eBGP 이웃으로 구성되어야 합니다. 하나의 CPE를 사용하는 경우, 각 원격 터널을 가리키는 두 개의 eBGP 이웃이 사용됩니다. 두 개의 CPE를 사용하는 경우, 각 CPE는 하나의 eBGP 이웃이 CPE에 대한 단일 원격 터널로 포팅됩니다.

  • 각 GRE 터널(터널 인터페이스 IP)의 시스코 측면은 CPE의 BGP 이웃으로 구성됩니다.

  • CPE는 각 터널에 대한 기본 경로를 광고해야 합니다.

  • CPE는 cutomer의 엔터프라이즈 네트워크 내에서 설정된 경로를 필요에 따라 재배포할 수 있습니다.

• 비-실패 링크 실패 조건 하에서, 단일 CPE는 두 개의 활성/활성 터널을 가진다. 두 개의 CPE 노드의 경우, 각 CPE는 하나의 활성 터널을 가지며, CPE 노드 모두 활성 및 전달 트래픽이어야 합니다. 비 실패 시나리오에서 트래픽은 올바른 / 25 목적지로 이동하는 두 개의 터널로 나뉘어야합니다. 터널 중 하나가 아래로 가면 나머지 터널은 둘 다 트래픽을 수행 할 수 있습니다. 이러한 실패 시나리오에서 /25 네트워크가 다운되면 /24 네트워크가 백업 경로로 사용됩니다. Cisco는 내부 WAN을 통해 연결이 끊긴 DC로 고객 트래픽을 전송합니다.

IPsec 터널 협상에는 IKEv2 단계와 IPsec 단계가 포함된다. IKEv2 단계 협상이 완료되지 않으면 두 번째 IPsec 단계가 시작되지 않습니다. 먼저 "show crypto 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 modulus 그룹을 확인합니다.

  • 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 터널 인터페이스가 활성화되어 있는지 확인하십시오. 장비가 GRE keepalives를 지원하지 않는 경우, 기본값의 전용 인스턴스 측에서 GRE keepalives가 활성화되므로 Cisco에 통지합니다. 전용 인스턴스 터널 IP의 이웃 주소로 BGP가 활성화되고 구성되었는지 확인합니다.

올바르게 구성되면 IPsec 터널과 첫 번째 단계 IKEv2 협상이 시작됩니다.

• CPE 측면 GRE 터널 인터페이스에서 전용 인스턴스 측면 GRE 터널 인터페이스로 GRE keepalives.

• CPE 측면 BGP 이웃에서 전용 인스턴스 측면 BGP 이웃으로 BGP 이웃 TCP 세션.

• CPE 사이드 터널 IP 주소에서 전용 인스턴스 사이드 터널 IP 주소로 핑.

  Ping은 터널 전송 IP로 터널 전송 IP가 될 수 없으며, 터널 IP로 터널 IP여야 합니다.

IKEv2 트래픽에 대해 패킷 추적이 필요한 경우 UDP 및 포트 500(NAT 장치가 IPsec 엔드포인트의 가운데에 없는 경우) 또는 포트 4500(NAT 장치가 IPsec 엔드포인트의 가운데에 삽입된 경우)에 대한 필터를 설정합니다.

포트 500 또는 4500이 포함된 IKEv2 UDP 패킷이 DI IPsec IP 주소로 전송 및 수신되는지 확인합니다.

전용 인스턴스 데이터 센터는 항상 첫 번째 IKEv2 패킷을 시작하지는 않을 수 있습니다. 요구 사항은 CPE 장치가 전용 인스턴스 측으로 첫 번째 IKEv2 패킷을 시작할 수 있다는 것입니다. 로컬 방화벽에서 허용하는 경우, 원격 IPsec 주소로 ping을 시도합니다. 로컬 IPsec 주소에서 원격 IPsec 주소로 핑이 성공적이지 않은 경우 추적 경로를 수행하여 도움을 주고 패킷이 삭제되는 위치를 결정합니다. 일부 방화벽 및 인터넷 장비는 추적 경로를 허용하지 않을 수 있습니다.

IPsec 두 번째 단계를 해결하기 전에 IPsec 첫 번째 단계(즉, IKEv2 보안 연계)가 활성화되었는지 확인합니다. "show crypto ikev2 sa" 또는 이와 동등한 명령을 수행하여 IKEv2 세션을 확인합니다. 출력에서 IKEv2 세션이 몇 초 이상 켜져 있으며 튕기지 않는지 확인합니다. 세션 가동 시간은 세션 "활성 시간" 또는 출력에 상응하는 것으로 표시됩니다.

IKEv2 세션이 up 및 active로 확인되면 IPsec 세션을 조사합니다. IKEv2 세션과 마찬가지로 "show crypto ipsec sa" 또는 이와 동등한 명령을 수행하여 IPsec 세션을 확인합니다. GRE 터널이 설정되기 전에 IKEv2 세션과 IPsec 세션이 모두 활성화되어야 합니다. IPsec 세션이 활성으로 표시되지 않는 경우, IPsec 로그에 오류 메시지 또는 협상 오류가 있는지 확인하십시오.

IPsec 협상 중에 발생할 수 있는 더 일반적인 문제 중 일부는 다음과 같습니다.

CPE 측의 설정이 전용 인스턴스 측과 일치하지 않습니다. 설정을 다시 확인하십시오.

• 암호화 및 인증 매개 변수가 전용 인스턴스 측의 설정과 일치하는지 확인합니다.

• Perfect Forward Secrecy 설정과 전용 인스턴스 측의 일치 설정을 확인합니다.

• 수명 설정을 확인합니다.

• IPsec이 터널 모드에서 구성되었는지 확인합니다.

• 소스 및 대상 IPsec 주소를 확인합니다.

IPsec 및 IKEv2 세션이 up 및 active로 확인되면 GRE tunnel keepalive 패킷은 전용 인스턴스 및 CPE 터널 엔드포인트 간에 흐를 수 있습니다. 터널 인터페이스가 상태를 표시하지 않는 경우, 몇 가지 일반적인 문제는 다음과 같습니다.

• 터널 인터페이스 전송 VRF는 루프백 인터페이스의 VRF와 일치하지 않습니다(터널 인터페이스에서 VRF 구성이 사용되는 경우).

  터널 인터페이스에서 VRF 구성이 사용되지 않는 경우 이 확인이 무시될 수 있습니다.

• CPE 사이드 터널 인터페이스에서 keepalives가 활성화되지 않음

  CPE 장비에서 keepalives가 지원되지 않는 경우, 전용 인스턴스 측의 기본 keepalives도 비활성화되도록 Cisco에 통지해야 합니다. keepalives가 지원되는 경우 keepalives가 활성화되었는지 확인합니다.

• 터널 인터페이스의 마스크 또는 IP 주소가 올바르지 않으며 전용 인스턴스 예상 값과 일치하지 않습니다.

• 소스 또는 대상 터널 전송 주소가 올바르지 않으며 전용 인스턴스 예상 값과 일치하지 않습니다.

• 방화벽이 GRE 패킷을 IPsec 터널로 전송하거나 IPsec 터널에서 수신하는 것을 차단합니다(GRE 터널은 IPsec 터널을 통해 전송됨).

핑 테스트는 로컬 터널 인터페이스가 켜져 있고 연결이 원격 터널 인터페이스에 적합한지 확인해야 합니다. 터널 IP(전송 IP 아님)에서 원격 터널 IP로 핑 검사를 수행합니다.

GRE 터널 트래픽을 운반하는 IPsec 터널에 대한 암호화 액세스 목록은 GRE 패킷만 교차 할 수 있습니다. 결과적으로, 핑은 터널 전송 IP에서 원격 터널 전송 IP로 작동하지 않습니다.

핑 검사에서 소스 터널 전송 IP에서 대상 터널 전송 IP로 생성되는 GRE 패킷이 생성되는 반면 GRE 패킷(내부 IP)의 페이로드는 소스 및 대상 터널 IP입니다.

핑 테스트가 성공적이지 않고 이전 항목이 확인되면 icmp ping이 GRE 패킷을 생성하여 IPsec 패킷에 캡슐화된 다음 소스 IPsec 주소에서 대상 IPsec 주소로 전송되도록 하려면 패킷 캡처가 필요할 수 있습니다. GRE 터널 인터페이스에 있는 카운터 및 IPsec 세션 카운터도 표시하는 데 도움이 될 수 있습니다. 패킷을 보내고 수신하는 경우 증가합니다.

핑 트래픽 외에도 캡처는 유휴 트래픽 중에도 keepalive GRE 패킷을 표시해야 합니다. 마지막으로 BGP가 구성된 경우 BGP keepalive 패킷은 IPSEC 패킷뿐만 아니라 VPN을 통해 캡슐화된 GRE 패킷으로도 전송되어야 합니다.

전용 인스턴스 측에서는 대규모 패킷 크기에 대해 MTU를 동적으로 조절할 수 있는 두 가지 기능이 활성화됩니다. GRE 터널은 VPN 세션을 통해 흐르는 IP 패킷에 더 많은 헤더를 추가합니다. IPsec 터널은 GRE 헤더 위에 추가 헤더를 추가하면 터널에서 허용되는 최대 MTU를 더욱 줄일 수 있습니다.

GRE 터널은 전용 인스턴스 측에서 MTU 검색 기능의 MSS 기능 및 GRE 터널 경로를 조정합니다. "ip tcp adjust-mss 1350" 또는 이와 동등한 명령과 "tunnel path\u0002mtu-discovery" 또는 이와 동등한 명령을 고객 측에서 구성하여 VPN 터널을 통한 트래픽 MTU의 동적 조정을 지원합니다.