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

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

아래 그림은 고객 측의 2-콘센트레이터 옵션에 대한 가상 연결 배포 모델의 예를 보여줍니다.

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

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

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

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

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 단계가 시작되지 않습니다. 먼저, Cisco 장비에서 "show crypto ikev2 sa" 명령을 실행하거나, 타사 장비에서 이와 유사한 명령을 실행하여 IKEv2 세션이 활성화되어 있는지 확인합니다. IKEv2 세션이 활성화되지 않은 경우 잠재적인 이유는 다음과 같습니다.

• 흥미로운 트래픽은 IPsec 터널을 트리거하지 않습니다.

• IPsec 터널 액세스 목록이 잘못 구성되었습니다.

• 고객과 전용 인스턴스 IPsec 터널 엔드포인트 IP 사이에 연결이 없습니다.

• IKEv2 세션 매개변수는 전용 인스턴스 측과 고객 측에서 일치하지 않습니다.

• 방화벽이 IKEv2 UDP 패킷을 차단하고 있습니다.

먼저, IKEv2 터널 협상의 진행 상황을 보여주는 메시지가 있는지 IPsec 로그를 확인하세요. 로그는 IKEv2 협상에 문제가 있는 곳을 나타낼 수 있습니다. 로깅 메시지가 없다는 것은 IKEv2 세션이 활성화되지 않았음을 나타낼 수도 있습니다.

IKEv2 협상에서 흔히 발생하는 오류는 다음과 같습니다.

• CPE 측의 IKEv2 설정이 Cisco 측과 일치하지 않습니다. 언급된 설정을 다시 확인하세요.

  • IKE 버전이 2인지 확인하세요.

  • 암호화 및 인증 매개변수가 전용 인스턴스 측에서 예상되는 암호화와 일치하는지 확인합니다.

    "GCM" 암호가 사용 중이면 GCM 프로토콜이 인증을 처리하고 인증 매개변수를 NULL로 설정합니다.

  • 수명 설정을 확인하세요.

  • 디피 헬만 모듈러스 그룹을 확인하세요.

  • 의사 난수 함수 설정을 확인하세요.

• 암호화 맵에 대한 액세스 목록이 설정되지 않았습니다.

  • 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 keepalive.

• 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 주소로 송수신되는지 확인합니다.

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

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

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

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

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

• 완벽한 전방 비밀성 설정을 확인하고 전용 인스턴스 측에서 일치 설정을 확인합니다.

• 수명 설정을 확인하세요.

• IPsec이 터널 모드로 구성되었는지 확인하세요.

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

IPsec 및 IKEv2 세션이 작동 중이고 활성 상태인 것으로 확인되면 GRE 터널 Keepalive 패킷이 전용 인스턴스와 CPE 터널 엔드포인트 사이를 흐를 수 있습니다. 터널 인터페이스 상태가 표시되지 않는 경우, 몇 가지 일반적인 문제는 다음과 같습니다.

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

  터널 인터페이스에서 VRF 구성을 사용하지 않으면 이 검사를 무시할 수 있습니다.

• CPE 측 터널 인터페이스에서는 Keepalive가 활성화되지 않습니다.

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

  Keepalive가 지원되는 경우 Keepalive가 활성화되어 있는지 확인하세요.

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

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

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

ping 테스트를 통해 로컬 터널 인터페이스가 작동 중인지, 원격 터널 인터페이스와의 연결이 양호한지 확인해야 합니다. 터널 IP(전송 IP가 아님)에서 원격 터널 IP로 ping 검사를 수행합니다.

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

ping 테스트가 성공적이지 않고 이전 항목이 검증된 경우, icmp ping이 GRE 패킷으로 생성되는지 확인하기 위해 패킷 캡처가 필요할 수 있습니다. 이 패킷은 IPsec 패킷으로 캡슐화된 후 소스 IPsec 주소에서 대상 IPsec 주소로 전송됩니다. GRE 터널 인터페이스의 카운터와 IPsec 세션 카운터도 전송 및 수신 패킷이 증가하는지 여부를 보여주는 데 도움이 될 수 있습니다.

ping 트래픽 외에도 캡처에서는 유휴 트래픽 중에도 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를 동적으로 조정하는 데 도움이 되는 고객 측의 동등한 명령입니다.