소개

가상 연결은 한 장치에서 라우팅 및 GRE 제어 평면을 제공하고 다른 장치에서 IPSec 제어 평면을 제공하는 이중 계층 헤드엔드 아키텍처를 사용합니다.

완료 시 가상 연결 연결의 경우, 2개의 GRE over IPSec 터널이 고객의 엔터프라이즈 네트워크와 전용 인스턴스 Cisco의 데이터 센터 간에 생성됩니다. 해당 리전 내의 각 중복 데이터 센터에 일대일. 피어링에 필요한 추가 네트워킹 요소는 파트너 또는 고객이 Control Hub 가상 연결 활성화 양식을 통해 Cisco 로 교환합니다.

그림 1은 고객 측의 2-집선 장치 옵션에 대한 Virtual Connect 배치 모델 의 예를 보여줍니다.

가상 연결 - VPN 은 고객의 허브 사이트가 특정 지역 내 전용 인스턴스 데이터 센터의 DC1 및 DC2에 연결되는 허브 설계입니다.

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

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

동일한 지역에 있는 고객의 원격 사이트는 고객의 WAN을 통해 허브 사이트에 다시 연결해야 하며, 해당 연결에 대한 Cisco의 책임은 없습니다.

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

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

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

• Cisco 는

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

  • 터널 전송 대상 주소(Cisco 측)

  • 고객 BGP 라우팅 구성을 위한 프라이빗 ASN(자동 시스템 번호)

    • Cisco 는 지정된 개인 사용 범위에서 다음을 할당합니다. 64512 - 65534

• 전용 인스턴스와 CPE 간에 라우트를 교환하는 데 사용되는 eBGP

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

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

  • CPE는 적절한 eBGP 인접 항목으로 구성되어야 합니다. 하나의 CPE를 사용하는 경우, 두 개의 eBGP 이웃이 사용되며, 하나는 각 원격 터널을 가리킵니다. 두 개의 CPE를 사용하는 경우, 각 CPE에는 CPE에 대한 단일 원격 터널로 연결되는 하나의 eBGP 인접 항목이 있습니다.

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

  • 각 터널을 통해 기본 경로를 알리려면 CPE가 필요합니다.

  • CPE는 필요에 따라 고객의 엔터프라이즈 네트워크 내에서 학습된 라우트를 재배포합니다.

• 비장애 링크 장애 조건에서 단일 CPE에는 두 개의 활성/활성 터널이 있습니다. 2개의 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 단계에 대한 협상 활동이 표시되지 않는 경우 패킷 캡처 가 필요할 수 있습니다.

전용 인스턴스 측에서 항상 IKEv2 교환을 시작하는 것은 아니며 고객 CPE 측에서 이니시에이터가 될 것으로 예상하는 경우가 있습니다. IKEv2 세션 시작을 위한 다음 사전 요구 사항에 대한 CPE 측 구성을 확인합니다. CPE 터널 전송 IP 에서 전용 인스턴스 터널 전송 IP 로의 GRE 트래픽(프로토콜 50)에 대한 IPsec 암호화 액세스 목록 을 확인합니다. GRE 킵얼라이브에 대해 GRE 터널 인터페이스가 활성화되어 있는지 확인합니다. 장비가 GRE 킵얼라이브를 지원하지 않는 경우, GRE 킵얼라이브가 기본적으로 전용 인스턴스 측에서 활성화되기 때문에 Cisco 에 알림을 보냅니다. BGP가 활성화되고 전용 인스턴스 터널 IP 의 인접 주소로 구성되었는지 확인합니다.

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

• CPE 측 GRE 터널 인터페이스에서 전용 인스턴스 측 GRE 터널 인터페이스로의 GRE 킵얼라이브.

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

• CPE 측 터널 IP 주소 에서 전용 인스턴스 측 터널 IP 주소 주소로 Ping합니다.

  Ping은 터널 전송 IP 대 터널 전송 IP 일 수 없으며, 터널 IP 대 터널 IP 여야 합니다.

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

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

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

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 터널 연결 유지 패킷은 전용 인스턴스와 CPE 터널 엔드포인트 간에 흐를 수 있습니다. 터널 인터페이스가 상태를 표시하지 않는 경우, 몇 가지 일반적인 문제는 다음과 같습니다.

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

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

• CPE 측 터널 인터페이스에서 연결 유지가 활성화되지 않음

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

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

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

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

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

GRE 터널 트래픽을 전달하는 IPsec 터널에 대한 암호화 액세스 목록 은 GRE 패킷만 통과하도록 허용합니다. 결과적으로 ping은 터널 전송 IP 에서 원격 터널 전송 IP 로 작동하지 않습니다.

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

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

핑 트래픽 외에도 캡처는 유휴 트래픽 중에도 연결 유지 GRE 패킷을 표시해야 합니다. 마지막으로, BGP가 구성된 경우, BGP 연결 유지 패킷은 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를 동적으로 조정하는 데 도움을 줍니다.