Virtual Connect는 이중 계층 헤드 아키텍처를 사용합니다. 이는 라우팅 및 GRE 제어 구성을 한 장치에서 제공하고 다른 장치에서 IPSec 제어 연결을 제공합니다.

가상 연결 연결이 완료되면 고객의 기업 네트워크 및 전용 인스턴스 Cisco의 데이터센터 사이에 두 개의 IPSec 터널이 생성됩니다. 해당 지역 내에서 한 개씩 중복되는 데이터 센터. 피어링에 필요한 추가 네트워킹 요소는 파트너 또는 고객이 Control Hub 가상 연결 활성화 양식을 통해 Cisco로 교환합니다.

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

Virtual Connect - VPN은 허브 디자인입니다. 이는 고객의 허브 사이트가 특정 지역에 있는 전용 인스턴스의 데이터센터의 DC1 및 DC2에 연결된 위치입니다.

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

파트너들은 고객과 긴밀히 협력해야 합니다. 이를 통해 'Virtual Connect' 서비스 지역을 위한 최적의 경로를 선택하십시오.

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

Virtual Connect 애드-인에 대한 라우팅은 전용 인스턴스와 고객 프레미스 장비(CPE) 간의 외부 BGP(eBGP)를 사용하여 실행됩니다. Cisco는 지역에 있는 각 중복되는 DC에 대해 해당 네트워크를 고객의 CPE로 광고하고, CPE가 Cisco로 기본 라우트를 광고해야 합니다.

• Cisco는 유지 관리 및 지정

  • 터널 인터페이스 IP 주소 지정 (라우팅을 위한 일시 링크) Cisco가 지정된 공유 주소 스페이스에서 지정 (공개적으로 라우팅할 수 없습니다)

  • 터널 전송 내선 주소 (Cisco 측)

  • 고객 BGP 라우팅 구성용 비공개 자율 시스템 번호(ASN)

    • Cisco는 지정된 비공개 사용 범위에서 지정: 64512 - 65534

• eBGP는 전용 인스턴스와 CPE 간의 라우트 교환에 사용

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

  • 가상 연결에서 각 /25 네트워크는 Cisco가 해당 지점 간 VPN 터널(일시 링크)을 통해 다시 CPE로 광고합니다.

  • CPE는 적합한 eBGP 이웃으로 구성되어야 합니다. 한 개의 CPE를 사용하는 경우, 두 개의 eBGP 이웃이 사용됩니다. 한 개의 점은 각 원격 터널을 예로 지점합니다. 두 개의 CPE를 사용하는 경우, 각 CPE에는 CPE에 대해 한 개의 원격 터널에 한 개의 eBGP 이웃이 설치됩니다.

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

  • CPE는 각 터널에 대해 기본 라우트 광고에 필요합니다.

  • CPE는 기업 네트워크 내에서 학습한 라우트에 따라 다시 재배포할 수 있습니다.

• 비-실패 링크 실패 조건에서 한 개의 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 단계에 대한 협상 활동을 표시하지 않는 경우, 패킷 캡처가 필요할 수 있습니다.

올바르게 구성되면 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 주소로 전송 및 수신되는지 확인합니다.

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로 핑 검사를 수행합니다.

핑 검사에서 소스 터널 전송 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의 동적 조정을 지원합니다.