가상 연결은 듀얼 티어 헤드엔드 아키텍처를 사용해요. 라우팅과 GRE 컨트롤 플레인은 한 장치에서 제공하고 IPsec 컨트롤 플레인은 다른 장치에서 제공해요.

가상 연결 연결이 완료되면 고객의 엔터프라이즈 네트워크와 전용 인스턴스 시스코의 데이터 센터 사이에 두 개의 GRE over IPsec 터널이 생성돼요. 각 지역 내의 중복 데이터 센터당 하나씩. 파트너나 고객이 컨트롤 허브 가상 연결 활성화 양식을 통해 피어링에 필요한 추가 네트워킹 요소를 Cisco로 교환해요.

아래 그림은 고객 측의 2-농축기 옵션에 대한 가상 연결 배포 모델의 예를 보여줘요.

가상 연결 - VPN은 고객의 허브 사이트가 특정 지역 내 전용 인스턴스 데이터센터의 DC1과 DC2에 연결되는 허브 디자인이에요.

중복성 향상을 위해 허브 사이트 두 개를 권장하지만 터널이 두 개인 허브 사이트 1개도 지원 배포 모델이에요.

파트너는 고객과 긴밀하게 협력하여 Virtual Connect 서비스 지역에 가장 적합한 경로를 선택해야 해요.

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

가상 연결 애드온의 라우팅은 전용 인스턴스와 고객 구내 장비 (CPE) 간의 외부 BGP (eBGP) 를 사용하여 구현돼요. 시스코는 고객 CPE에 지역 내 각 중복 DC에 대한 해당 네트워크를 광고할 거예요. 그리고 Cisco에 기본 경로를 광고하려면 CPE가 필요해요.

• 시스코가 유지 관리하고 할당해요

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

  • 터널 운송 목적지 주소 (시스코 측)

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

    • 시스코는 지정된 개인 사용 범위에서 할당해요: 64512부터 65534까지

• eBGP는 전용 인스턴스와 CPE 사이에서 경로를 교환하는 데 사용돼요

  • 시스코는 할당된 /24 네트워크를 각 지역의 DC당 2/25 네트워크로 나눌 거예요

  • 버추얼 커넥트에서 Cisco는 각 /2.5 네트워크를 각각의 포인트-투-포인트 VPN 터널 (임시 링크) 을 통해 CPE에 다시 광고해요.

  • CPE가 적절한 eBGP 이웃으로 구성되어야 해요. CPE 하나를 사용하면 eBGP 이웃 두 개가 사용돼요. 하나는 각 원격 터널을 가리키죠. CPE를 두 개 사용하는 경우, CPE마다 CPE의 단일 원격 터널을 가리키는 eBGP 이웃 1개가 있어요.

  • 각 GRE 터널의 시스코 측 (터널 인터페이스 IP) 이 CPE의 BGP 인접 디바이스로 구성돼요

  • 각 터널에 기본 경로를 광고하려면 CPE가 필요해요

  • CPE가 필요에 따라 고객의 기업 네트워크 내에서 학습한 경로를 재배포하는 일을 담당해요.

• 무장애 링크 장애 상태에서는 단일 CPE에 활성/활성 터널이 두 개 있을 거예요. CPE 노드 2개에 대해 각 CPE에는 활성 터널이 하나씩 있고 CPE 노드 두 개 모두 활성 상태이고 트래픽을 통과해야 해요. 무장애 시나리오에서는 트래픽을 두 터널로 나누어 올바른 /25 목적지로 가야 해요. 터널 중 하나가 다운되면 나머지 터널이 양쪽 목적지로 트래픽을 전송할 수 있어요. 그런 실패 시나리오에서 /25 네트워크가 다운되면 /24 네트워크가 백업 경로로 사용돼요. 시스코는 내부 WAN을 통해 연결이 끊긴 DC로 고객 트래픽을 보낼 거예요.

IPsec 터널 협상에는 두 단계, IKEv2 단계와 IPsec 단계가 포함돼요. IKEv2 단계 협상이 완료되지 않으면 두 번째 IPsec 단계는 시작되지 않아요. 먼저 타사 장비에서 “show crypto ikev2 sa” 명령 또는 유사한 명령을 실행하여 IKEv2 세션이 활성 상태인지 확인하세요. IKEv2 세션이 활성화되지 않은 경우, 잠재적 원인은 다음과 같을 수 있어요.

• 재밌네요 트래픽은 IPsec 터널을 트리거하지 않아요.

• IPsec 터널 액세스 목록이 잘못 구성됐어요.

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

• IKEv2 세션 파라미터가 전용 인스턴스 측과 고객 측 사이가 일치하지 않아요.

• 방화벽이 IKEv2 UDP 패킷을 차단하고 있어요.

먼저 IPsec 로그에서 IKEv2 터널 협상 진행 상황을 보여주는 메시지가 있는지 확인하세요. 로그에 IKEv2 협상에 문제가 있는 부분이 표시될 수 있어요. 로깅 메시지가 없으면 IKEv2 세션이 활성화되지 않고 있다는 의미일 수도 있어요.

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

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

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

  • 암호화와 인증 파라미터가 전용 인스턴스 측의 예상 암호화와 일치하는지 확인하세요.

    “GCM” 암호가 사용 중이면 GCM 프로토콜이 인증을 처리하고 인증 매개변수를 NULL로 설정해요.

  • 수명 설정 확인해요.

  • 디피 헬만 모듈러스 그룹 검증해요.

  • 유사 랜덤 함수 설정 확인.

• 크립토 맵의 접속 목록은 다음과 같이 설정되지 않았어요.

  • GRE (로컬_터널_수송_IP) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (또는 이에 상응하는 명령) 허용

    액세스 목록은 “GRE” 프로토콜 전용이어야 하고 “IP” 프로토콜은 작동하지 않아요.

로그 메시지에 IKEv2 단계에 대한 협상 활동이 표시되지 않으면 패킷 캡처가 필요할 수 있어요.

제대로 구성되면 다음과 같이 IPsec 터널과 1단계 IKEv2 협상이 시작돼요.

• GRE는 CPE 측 GRE 터널 인터페이스에서 전용 인스턴스 측 GRE 터널 인터페이스로 유지돼요.

• CPE 측 BGP 인접 디바이스에서 전용 인스턴스 측 BGP 인접 디바이스로의 BGP 인접 디바이스로의 BGP 인접 디바이스로의 BGP 인접 디바이스.

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

  핑은 터널 전송 IP 대 터널 전송 IP일 수 없어요. 터널 IP 대 터널 IP여야 해요.

IKEv2 트래픽에 패킷 추적이 필요하면 UDP에 대한 필터를 설정하고 포트 500 (IPsec 엔드포인트 중간에 NAT 장치가 없는 경우) 또는 포트 4500 (IPsec 엔드포인트 중간에 NAT 장치가 삽입된 경우) 으로 설정하세요.

포트 500 또는 4500의 IKEv2 UDP 패킷이 DI IPsec IP 주소로 송수신되는지 확인하세요.

IPsec 두 번째 단계 문제 해결 전에 IPsec 첫 번째 단계 (즉, IKEv2 보안 연결) 가 활성화되어 있는지 확인하세요. IKEv2 세션을 확인하려면 “show crypto ikev2 sa” 또는 이에 상응하는 명령을 실행하세요. 출력에서 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 측 터널 인터페이스에서는 킵얼라이브가 활성화되지 않아요

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

  킵얼라이브가 지원되면 킵얼라이브가 활성화되어 있는지 확인해 주세요.

• 터널 인터페이스의 마스크나 IP 주소가 올바르지 않고 전용 인스턴스 예상값과 일치하지 않아요.

• 소스 또는 대상 터널 전송 주소가 올바르지 않고 전용 인스턴스 예상값과 일치하지 않아요.

• IPsec 터널로 보내거나 IPsec 터널에서 받는 GRE 패킷을 방화벽이 차단하고 있어요 (GRE 터널은 IPsec 터널을 통해 전송됨)

핑 테스트로 로컬 터널 인터페이스가 작동 중이고 원격 터널 인터페이스와의 연결 상태가 양호한지 확인해야 해요. 터널 IP (전송 IP 아님) 에서 원격 터널 IP로 핑 검사를 수행해요.

핑 체크 결과 소스 터널 전송 IP에서 대상 터널 전송 IP로 GRE 패킷이 생성되고 GRE 패킷 (내부 IP) 의 페이로드는 소스 및 대상 터널 IP가 돼요.

핑 테스트에 실패하고 이전 항목이 확인되면 icmp 핑으로 인해 GRE 패킷이 생성되고 IPsec 패킷으로 캡슐화된 다음 소스 IPsec 주소에서 대상 IPsec 주소로 전송되는지 확인하기 위해 패킷 캡처가 필요할 수 있어요. GRE 터널 인터페이스의 카운터와 IPsec 세션 카운터도 보여주는 데 도움이 될 수 있어요. 송수신 패킷이 증가하는지 여부.

핑 트래픽 외에도 캡처에는 유휴 트래픽 중에도 keepalive GRE 패킷이 표시되어야 해요. 마지막으로, BGP가 구성된 경우 BGP 킵얼라이브 패킷도 VPN을 통해 IPSEC 패킷에 캡슐화된 GRE 패킷으로 보내야 해요.

전용 인스턴스 쪽에서는 큰 패킷 크기에 맞게 MTU를 동적으로 조정하는 기능이 두 개 활성화되어 있어요. GRE 터널은 VPN 세션을 통해 흐르는 IP 패킷에 더 많은 헤더를 추가해요. IPsec 터널이 GRE 헤더 위에 헤더를 추가하면 터널에 허용되는 최대 MTU가 더 줄어들어요.

GRE 터널은 MSS 기능을 조정하고 MTU 검색 기능의 GRE 터널 경로는 전용 인스턴스 측에서 활성화돼요. VPN 터널을 통한 트래픽의 MTU를 동적으로 조정하는 데 도움이 되도록 고객 측에서 “ip tcp adjust-mss 1350" 또는 이에 상응하는 명령과 “tunnel path\ u0002mtu-discovery” 또는 이에 상응하는 명령을 구성하세요.