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

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

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

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

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

파트너는 고객과 긴밀하게 작업하여 가상 연결 서비스 지역에 대해 가장 최적의 경로가 선택되도록 합니다.

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

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 패킷을 차단하고 있습니다.

먼저 IKEv2 터널 협상 진행 상황을 보여주는 메시지에 대해 IPsec 로그를 확인합니다. 로그는 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 단계에 대한 협상 활동을 표시하지 않는 경우 패킷 캡처가 필요할 수 있습니다.

올바르게 구성되면 다음은 IPsec 터널 및 첫 번째 단계 IKEv2 협상을 시작합니다.

• GRE는 CPE 측 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 세션이 활성 상태로 확인되면 IPsec 세션을 조사합니다. IKEv2 세션과 마찬가지로 "show crypto ipsec sa" 또는 이에 상응하는 명령을 수행하여 IPsec 세션을 확인합니다. GRE 터널이 설정되기 전에 IKEv2 세션과 IPsec 세션이 모두 활성화되어야 합니다. IPsec 세션이 활성 상태로 표시되지 않으면 오류 메시지 또는 협상 오류에 대해 IPsec 로그를 확인합니다.

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

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

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

• Perfect Forward Secrecy 설정을 확인하고 전용 인스턴스 측의 설정이 일치하는지 확인합니다.

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

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

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

IPsec 및 IKEv2 세션이 켜져 있는 것으로 확인되면 GRE 터널 KEEPALIVE 패킷은 전용 인스턴스와 CPE 터널 엔드포인트 간에 플로우할 수 있습니다. 터널 인터페이스가 상태가 표시되지 않는 경우, 몇 가지 일반적인 문제는 다음과 같습니다.

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

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

• CPE 측면 터널 인터페이스에서 Keepalives가 활성화되지 않음

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

  keepalives가 지원되는 경우, keepalives가 활성화되었는지 확인합니다.

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

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

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

핑 테스트는 로컬 터널 인터페이스가 켜져 있고 연결이 원격 터널 인터페이스에 양호한지 확인해야 합니다. 전송 IP가 아닌 터널 IP에서 원격 터널 IP로 핑 확인을 수행합니다.

핑 확인은 소스 터널 전송 IP에서 대상 터널 전송 IP로 생성된 GRE 패킷을 출력하며, GRE 패킷(내부 IP)의 페이로드는 소스 및 대상 터널 IP가 됩니다.

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

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

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

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