Cloud Router 개요

Cloud Router는 커스텀 동적 경로를 프로그래밍하고 네트워크 트래픽에 따라 확장되는 완전 분산형 및 관리형 Google Cloud 서비스입니다. Cloud Router는 기존 네트워크와 Virtual Private Cloud(VPC) 네트워크 모두에서 작동합니다.

Cloud Router는 연결 옵션이 아니지만 Cloud VPN 또는 Interconnect 연결을 통해 작동하여 경계 게이트웨이 프로토콜(BGP)로 VPC 네트워크에 동적 라우팅을 제공하는 서비스입니다. 다이렉트 피어링 또는 이동통신사 피어링 연결에는 Cloud Router가 지원되지 않습니다.

Cloud Router는 병목 현상을 일으킬 수 있는 실제 기기가 아니며 단독으로 사용할 수 없습니다. 그러나 다음 경우에는 필수이거나 사용하는 것이 좋습니다.

  • Cloud NAT에 필요
  • Cloud Interconnect 및 HA VPN에 필요
  • 기본 VPN에 권장되는 구성 옵션

온프레미스 네트워크를 Google Cloud로 확장할 경우 Cloud Router를 사용하여 Google Cloud 네트워크와 온프레미스 네트워크 간에 경로를 동적으로 교환합니다. Cloud Router는 온프레미스 VPN 게이트웨이 또는 라우터와 피어링됩니다. 라우터는 BGP를 통해 토폴로지 정보를 교환합니다.

토폴로지 변경사항은 VPC 네트워크와 온프레미스 네트워크 간에 자동으로 전파됩니다. Cloud Router를 사용할 때는 정적 경로를 구성할 필요가 없습니다.

Cloud Router 소프트웨어 태스크

Cloud Router는 1~2개 또는 드물게 3의 소프트웨어 태스크로 구현됩니다.

다음 표에는 시나리오 예시와 각 시나리오에서 Cloud Router를 구현하는 데 Google Cloud에서 사용하는 소프트웨어 태스크 수가 나와 있습니다.

  • 표에 나열된 HA 구성의 경우 소프트웨어 중복을 제공하기 위해 두 개의 소프트웨어 태스크가 사용됩니다.
  • VLAN 연결의 경우 에지 연결이 있는 각 에지 가용성 도메인이 별도의 소프트웨어 태스크로 처리됩니다.
예시 시나리오 Cloud Router를 구현하는 데 사용되는 소프트웨어 태스크 수
각각 기본 VPN 터널에 연결된 하나 이상의 인터페이스 1
VLAN 연결이 동일한 에지 가용성 도메인에 있는 VLAN 연결에 연결된 하나 이상의 인터페이스 1
터널이 모두 하나 이상의 HA VPN 게이트웨이의 동일한 인터페이스 번호로 연결된 HA VPN 터널에 연결된 인터페이스 수(예: 여러 HA VPN 게이트웨이의 interface 0에 연결된 2개의 터널). 1
인터페이스 2개 이상(한 개의 인터페이스는 단일 에지 가용성 도메인의 VLAN 연결에 연결되고 다른 한 개의 인터페이스는 에지 가용성 도메인과 VPN 게이트웨이 인터페이스 번호가 동일한 단일 HA VPN 터널에 연결됨).(예: 에지 가용성 도메인과 첫 번째 VPN 게이트웨이 인터페이스 페어의 첫 번째 에지 가용성 도메인) 1
VLAN 연결이 서로 다른 에지 가용성 도메인에 있는 VLAN 연결에 연결된 2개 이상의 인터페이스 2
HA VPN 터널에 연결된 2개 이상의 인터페이스. 각 터널은 서로 다른 HA VPN 게이트웨이 인터페이스 번호에 연결됩니다(예: 한 터널은 HA VPN 게이트웨이의 interface 0에 연결되고 다른 터널은 동일한 게이트웨이 또는 다른 게이트웨이의 interface 1에 연결). 2
다음이 포함된 Cloud Router:
  • edge availability domain 0의 VLAN 연결에 연결된 인터페이스 1개 또는 HA VPN 게이트웨이의 interface 0에 연결된 HA VPN 터널에 연결된 인터페이스 1개
  • edge availability domain 1의 VLAN 연결에 연결된 인터페이스 1개 또는 HA VPN 게이트웨이의 interface 1에 연결된 HA VPN 터널에 연결된 인터페이스 1개
  • 기본 VPN 터널에 연결된 인터페이스 1개
3

정적 라우팅

정적 경로에서는 라우팅 테이블을 만들거나 유지관리해야 합니다. 두 네트워크에서 토폴로지를 변경하려면 수동으로 정적 경로를 업데이트해야 합니다. 연결이 실패하면 정적 경로가 자동으로 트래픽을 다시 라우팅할 수 없습니다.

정적 라우팅은 안정적인 토폴로지가 있는 소규모 네트워크에 적합합니다. 또한 라우팅 테이블을 엄격하게 제어할 수 있습니다. 라우터는 네트워크 간에 공지를 보내지 않습니다.

Cloud VPN 터널의 정적 라우팅

Cloud Router가 없으면 정적 경로만 사용하여 Cloud VPN 터널을 구성할 수 있습니다. 정적 경로 사용 시의 단점은 다음과 같습니다.

  • Cloud VPN 터널의 양쪽에서 네트워크 구성이 변경되면 변경사항에 맞게 정적 경로를 수동으로 만들고 삭제해야 합니다. 또한 정적 경로 변경은 수렴 속도가 느립니다.
  • 정적 경로와 작동하도록 Cloud VPN 터널을 만들 때는 터널이 생성되기 전에 터널 양쪽에 IP 프리픽스 목록을 지정해야 합니다. 즉, 경로가 바뀔 때마다 Cloud VPN 터널을 삭제한 후 다시 만들고 새 경로를 구성해야 하므로 기존 트래픽이 중단됩니다.
  • 정적 경로를 구성하는 표준 방법은 없습니다. 공급업체마다 다른 명령어를 사용합니다.

Cloud Router를 배포하면 정적 경로와 Cloud VPN 터널의 구성 변경을 방지할 수 있습니다. Cloud Router는 BGP를 통해 토폴로지 정보를 교환하여 Cloud VPN 게이트웨이와 피어링합니다. 사실상 Google Cloud 네트워크의 네트워크 토폴로지 변경사항은 BGP를 통해 자동으로 고유한 네트워크로 전파되므로 Cloud VPN 터널의 정적 경로를 구성할 필요가 없습니다.

동적 라우팅

Cloud Router를 사용하면 BGP를 통해 네트워크 간에 라우팅 정보를 교환할 수 있습니다. 정적 경로를 수동으로 구성하는 대신 네트워크가 BGP를 통해 토폴로지 변경사항을 자동으로 신속하게 검색합니다. 변경사항이 트래픽을 방해하지 않으면서 원활하게 구현됩니다. BGP를 통해 경로를 교환하는 이 방법을 동적 라우팅이라고 합니다.

동적 라우팅은 모든 규모의 네트워크에 적합합니다. 정적 경로를 유지관리할 필요가 없으며 연결이 실패하면 가능한 경우 동적 라우팅이 자동으로 트래픽의 경로를 변경할 수 있습니다. 동적 라우팅을 사용하려면 Cloud Router를 생성합니다. 그런 다음 Cloud Router와 온프레미스 게이트웨이 또는 라우터 간에 BGP 세션을 구성합니다.

Cloud Interconnect 및 Cloud VPN에 대한 동적 라우팅 요구사항

다음을 수행하려면 기존 Cloud Router가 있어야 합니다.

Cloud Router를 만들 때 Google 측 ASN을 선택할 수 있습니다. ASN을 지정하지 않으면 Google Cloud가 ASN을 자동으로 선택합니다. 그러나 Cloud Router의 구성 설정에서 온프레미스(피어) 라우터의 ASN을 수동으로 지정해야 합니다.

다음 방법으로 BGP IP 주소를 지정할 수 있습니다.

  • Dedicated Interconnect에서는 사용자가 IP 주소 범위를 지정하거나 Google Cloud가 선택하도록 지정할 수 있습니다.
  • Partner Interconnect의 경우 BGP IP 주소를 지정하지 않습니다.
  • 동적 라우팅을 사용하는 HA VPN 및 기본 VPN의 경우, Cloud Router에서 BGP 인터페이스를 만들 때 BGP IP 주소를 지정할 수 있습니다.

다음 두 섹션에서는 리전별 동적 라우팅 및 전역 동적 라우팅의 예시를 설명합니다. VPC 네트워크의 동적 라우팅 모드에 대한 자세한 내용은 VPC 문서의 VPC 네트워크 개요를 참조하세요.

동적 라우팅 모드 및 부하 분산기에 대한 자세한 내용은 Cloud Load Balancing 문서의 내부 부하 분산기 및 연결된 네트워크를 참조하세요.

리전별 동적 라우팅 예시

리전별 동적 라우팅을 사용하면 단일 Google Cloud 리전에 Cloud VPN 터널 및 가상 머신(VM) 인스턴스가 있을 수 있습니다. 터널은 온프레미스 네트워크를 VPC 네트워크로 확장합니다. 다른 리전의 VM은 온프레미스 네트워크에 연결해야 하지만 터널에 연결할 수 없습니다. 이 제약을 피하기 위해 정적 경로를 만들 수 있으나, 정적 경로를 유지하면 오류가 발생하여 트래픽이 중단될 수 있습니다.

다음 다이어그램에서 Cloud Router는 us-west1 리전의 리소스만 볼 수 있습니다. us-central1과 같은 다른 리전에 있는 VM은 Cloud VPN 터널에 연결할 수 없습니다.

Cloud Router 리전별 동적 라우팅
Cloud Router 리전별 동적 라우팅(확대하려면 클릭)

전역 동적 라우팅 예시

전역 동적 라우팅을 사용하면 Cloud Router가 모든 리전의 리소스를 볼 수 있습니다. 예를 들어 한 리전에 VM이 있는 경우 정적 경로를 유지하지 않고 다른 리전의 Cloud VPN 터널에 자동으로 연결할 수 있습니다.

다음 다이어그램에서는 전역 동적 라우팅을 사용하는 VPC 네트워크를 보여줍니다. us-west1의 Cloud Router는 리전 두 개(us-west1us-central1)에 있는 서브넷을 공지합니다. 두 리전에 있는 VM은 온프레미스 호스트를 동적으로 학습합니다.

Cloud Router 전역 동적 라우팅
Cloud Router 전역 동적 라우팅(확대하려면 클릭)

중복 토폴로지의 경우 동적 라우팅(BGP)이 VPC와 온프레미스 네트워크에 충분한 정보를 제공하므로 경로에 장애가 발생하면 트래픽이 다시 라우팅됩니다. 한 리전에서 연결 문제가 발생하면 트래픽은 다른 리전으로 장애 조치됩니다.

경로 공지

Cloud Router는 BGP를 통해 온프레미스 네트워크의 클라이언트가 연결할 수 있는 IP 주소를 공지합니다. 온프레미스 네트워크는 공지된 IP 범위와 일치하는 대상 IP 주소를 가진 VPC 네트워크로 패킷을 전송합니다. Google Cloud에 연결하면 VPC 네트워크의 방화벽 규칙과 경로에 따라 Google Cloud가 패킷을 처리하는 방법이 결정됩니다.

Cloud Router의 기본 공지를 사용하거나 공지할 CIDR 범위를 명시적으로 지정할 수 있습니다. 공지를 지정하지 않으면 Cloud Router가 기본값을 사용합니다.

기본 경로 공지

기본적으로 Cloud Router는 리전별 동적 라우팅의 경우 해당 리전의 서브넷에 공지하고, 글로벌 동적 라우팅의 경우 VPC 네트워크의 모든 서브넷에 공지합니다. Cloud Router는 새 서브넷을 자동으로 공지합니다. 또한 서브넷에 별칭 IP 주소를 구성할 수 있도록 보조 IP 범위가 있는 경우 Cloud Router는 기본 및 보조 IP 주소를 모두 공지합니다.

Cloud Router의 각 BGP 세션에는 기본 공지가 있습니다. 기본적으로 Cloud Router는 경로 공지를 모든 BGP 세션에 전파합니다. Cloud Router에 커스텀 경로 공지를 구성하면 BGP 세션이 이 커스텀 공지를 상속합니다.

다음과 같은 경우 커스텀 경로 공지를 지정합니다.

  • 서브넷의 기본 IP 범위를 벗어나거나 보조 IP 범위 중 하나를 벗어난 IP 주소를 공지하려는 경우(예: 외부 IP 주소 공지).

  • VPC 네트워크 피어링을 통해 VPC 네트워크에 연결된 다른 VPC 네트워크에서 경로를 공지하려는 경우. 이 경우 피어 네트워크의 서브넷 경로와 가져온 커스텀 경로가 VPC 네트워크의 Cloud Router에서 자동으로 공지되지 않습니다. 이를 공지하려면 VPC 네트워크의 Cloud Router에서 커스텀 경로 공지를 만들어야 합니다. 또한 VPC 네트워크 피어링 연결이 커스텀 경로를 교환하도록 구성되어 있는지 확인해야 합니다.

커스텀 공지를 사용하면 서브넷 또는 서브넷의 일부를 선택적으로 공지할 수 있습니다. 그러면 특정 서브넷을 공지하지 않도록 보류할 수 있습니다. 이러한 기능이 필요 없으면 기본 공지를 사용합니다.

커스텀 경로 공지

커스텀 경로 공지를 구성할 때 Cloud Router가 공지하는 경로를 명시적으로 지정하세요. 대부분의 경우 커스텀 공지는 커스텀 IP 주소로 기본 서브넷 공지를 보완하는 데 유용합니다. 커스텀 IP 주소는 예약된 외부 IP 주소와 같이 서브넷 IP 범위를 벗어난 주소입니다. 커스텀 경로 공지가 없으면 커스텀 IP 주소에 대한 정적 경로를 만들고 유지관리해야 합니다.

커스텀 경로 공지를 구성할 때 기본 동작을 에뮬레이션하는 모든 서브넷을 공지하도록 선택할 수 있습니다. 모든 서브넷을 공지하지 않고 서브넷 내 특정 서브넷 또는 특정 CIDR 블록을 대신 공지하도록 선택할 수 있습니다. 예를 들어 Cloud Router가 특정 서브넷을 공지하지 못하도록 할 수 있습니다. 그렇게 하려면 공개하려는 서브넷만 공지해야 합니다. 하지만 선택적으로 서브넷을 공지할 때는 커스텀 경로 공지에 새 서브넷을 수동으로 추가해야 합니다. Cloud Router는 새 서브넷을 자동으로 공지하지 않습니다.

Cloud Router나 BGP 세션에서 커스텀 경로 공지를 지정할 수 있습니다. Cloud Router의 커스텀 경로 공지는 모든 BGP 세션에 적용됩니다. 하지만 BGP 세션에서 커스텀 경로 공지를 지정하면 BGP 세션의 경로 공지가 Cloud Router의 경로 공지를 무시하고 재정의합니다.

Cloud Router마다 최대 200개의 CIDR 범위를 지정할 수 있습니다. 각 BGP 세션은 동일하게 200개로 제한됩니다.

경로 공지의 예

다음 예시에서는 커스텀 경로 공지가 유용할 수 있는 Cloud Router의 기본 동작 및 시나리오를 보여줍니다. 이 예시에서는 IPsec VPN 터널 또는 Dedicated Interconnect 연결과 같은 온프레미스 네트워크와 VPC 간의 기존 연결을 가정합니다.

기본 경로 공지

리전별 동적 라우팅의 경우 Cloud Router가 해당 리전의 서브넷을 공지합니다. 다음 다이어그램에서 Cloud Router는 us-central1 리전의 서브넷을 공지합니다. 또한 alias-subnet의 보조 IP 범위를 공지합니다. us-central1에 새 서브넷을 만들면 Cloud Router는 이를 자동으로 공지합니다. Cloud Router는 외부 IP 주소와 같이 서브넷의 IP 범위에 포함되지 않은 IP 주소를 공지하지 않습니다.

Cloud Router 기본 경로 공지.
Cloud Router 기본 경로 공지(확대하려면 클릭)

외부 IP 주소 공지

온프레미스 네트워크의 클라이언트에 서비스를 제공하는 Google Cloud 애플리케이션에 외부 정적 IP 주소를 사용할 수 있습니다. 애플리케이션에 유지보수를 수행할 때 정적 IP 주소를 다른 VM으로 다시 매핑하면 다운타임을 최소화할 수 있습니다. Cloud Router의 기본 공지를 사용하려면 정적 경로를 구성하고 유지관리해야 합니다. 대신 커스텀 공지를 사용하여 BGP를 통해 외부 IP 주소를 공지할 수 있습니다.

다음 다이어그램에서 Cloud Router는 프록시 서버의 외부 IP 주소 1.2.3.4를 공지합니다. 외부 IP 주소가 서버의 내부 IP 주소 10.20.0.2에 매핑됩니다. Cloud Router는 프록시 서버 또는 my-subnet 서브넷에 있는 VM의 내부 IP 주소를 공지하지 않습니다. 온프레미스 클라이언트는 프록시 서버의 외부 IP 주소만 인식합니다.

외부 IP 주소 공지.
외부 IP 주소 공지(확대하려면 클릭)

자세한 내용은 커스텀 IP 범위 공지를 참조하세요.

서브넷 공지 제한

인스턴스가 공지되지 않도록 숨길 수 있습니다. 다음 다이어그램에서 Cloud Router는 subnet-1subnet-2를 공지합니다. 온프레미스 네트워크의 클라이언트는 해당 서브넷의 VM에 연결할 수 있지만 unadvertised-subnet 서브넷의 VM에는 연결할 수 없습니다.

Cloud Router에서 특정 서브넷을 공지합니다.
Cloud Router에서 특정 서브넷 공지(확대하려면 클릭)

자세한 내용은 특정 VPC 서브넷 공지를 참조하세요.

BGP 세션당 경로 공지

VPC 네트워크 및 온프레미스 네트워크에 프로덕션 및 테스트 리소스가 있고 이러한 리소스를 서로 다른 서브넷에 구성했다고 가정합니다. 이에 따라 서로 다른 IP 주소 범위를 공지하는 BGP 세션 두 개를 설정합니다. BGP 세션 두 개를 사용하면 한 서브넷으로 향하는 트래픽이 실수로 다른 서브넷으로 이동하지 않습니다. 다음 예시에서는 prod-subnet만 공지하는 prod-bgptest-subnet만 공지하는 test-bgp라는 두 BGP 세션을 보여줍니다.

BGP 세션의 특정 서브넷을 공지합니다.
BGP 세션의 특정 서브넷 공지(확대하려면 클릭)

자세한 내용은 커스텀 IP 범위 공지 또는 특정 VPC 서브넷 공지를 참조하세요.

커스텀 동적 경로 학습

Cloud Router가 동일한 대상 프리픽스에 대해 여러 개의 다음 홉을 수신하면 Google Cloud는 경로 측정항목을 사용하며 경우에 따라 AS 경로 길이를 사용하여 VPC 네트워크에서 커스텀 동적 경로를 만듭니다. 다음 섹션에서는 이 과정을 설명합니다.

동적 라우팅 모드의 영향

VPC 네트워크의 동적 라우팅 모드는 Cloud Router에서 학습된 커스텀 동적 경로를 적용하는 방식을 결정합니다.

  • 리전 동적 라우팅 모드에서 Cloud Router는 Cloud Router와 동일한 리전에서 대상 및 다음 홉에 대한 커스텀 지정 동적 경로를 만듭니다. Cloud Router는 해당 커스텀 동적 경로의 우선순위를 기본 우선 순위로 설정합니다. 기본 우선순위는 Cloud Router가 온프레미스 라우터에서 공지하는 multi-exit discriminator(MED)에서 가져옵니다.

  • 글로벌 동적 라우팅 모드에서 Cloud Router는 각 Google Cloud 리전의 대상 및 다음 홉에 대한 커스텀 동적 경로를 만듭니다. 해당 경로를 학습한 Cloud Router가 포함된 리전에서 Cloud Router는 커스텀 동적 경로의 우선순위를 기본 우선순위로 설정합니다. 다른 모든 리전에서 Cloud Router는 우선순위를 기본 우선순위로 설정하고 적절한 리전 간 비용을 설정합니다.

온프레미스 라우터로 내보낸 Google Cloud로의 경로에 대해 경로 우선순위로 정의할 수 있습니다. 하지만 온프레미스 라우터가 구성에 따라 이 경로 우선순위를 재정의할 수 있습니다(예: 온프레미스 라우터가 경로 우선순위를 수정하는 경우).

Cloud Router가 학습한 온프레미스 경로의 경우 Cloud Router는 다음 두 섹션에 설명된 대로 AS 경로 길이와 MED 값을 가져오고 기본 우선순위를 계산합니다.

AS 경로 프리펜딩 및 AS 경로 길이

AS 경로 프리펜딩은 대상(프리픽스)의 다음 홉이 의도적으로 우선순위에서 밀려나고 AS 경로 길이가 더 짧은 동일한 대상의 다른 다음 홉이 선택되는 방식입니다. MED는 다음 홉의 AS 경로 길이가 동일할 때만 고려됩니다.

Google Cloud는 AS 경로를 사용하여 동일한 Cloud Router 소프트웨어 태스크에 의해 구현된 BGP 세션 간에 다음 홉을 선택할 수 있습니다.

Google Cloud에서 AS 경로를 사용하는 방법

AS 경로 프리펜딩은 제어 영역 및 VPC 네트워크와 관련이 없습니다. AS 경로 길이는 다음 시나리오에서 설명하는 것처럼 각 Cloud Router 소프트웨어 태스크 내에서만 고려됩니다.

단일 Cloud Router 소프트웨어 태스크가 두 개 이상의 BGP 세션에서 동일한 대상을 학습하는 경우:

  • 소프트웨어 태스크는 AS 경로 길이가 가장 짧은 다음 홉 BGP 세션을 선택합니다.
  • 소프트웨어 태스크가 대상, 다음 홉, MED 정보를 Cloud Router 제어 영역에 제출합니다.
  • 제어 영역은 이 정보를 사용하여 하나 이상의 후보 경로를 만듭니다. 각 후보의 기본 우선순위는 MED 수신됨으로 설정됩니다.

두 개 이상의 Cloud Router 소프트웨어 태스크가 두 개 이상의 BGP 세션에서 동일한 대상을 학습하는 경우:

  • 각 소프트웨어 태스크는 AS 경로 길이가 가장 짧은 다음 홉 BGP 세션을 선택합니다.
  • 각 소프트웨어 태스크가 대상, 다음 홉, MED 정보를 Cloud Router 제어 영역에 제출합니다.
  • 제어 영역은 이 정보를 사용하여 두 개 이상의 후보 경로를 만듭니다. 각 후보의 기본 우선순위는 MED 수신됨으로 설정됩니다.

그러면 Cloud Router 제어 영역이 VPC 네트워크의 동적 라우팅 모드에 따라 VPC 네트워크에 커스텀 동적 경로를 하나 이상 설치합니다. 전역 동적 라우팅 모드에서 Cloud Router 리전과 다른 리전에서 각 리전별 커스텀 동적 경로의 우선순위가 조정됩니다. Google Cloud가 경로를 선택하는 방법에 대한 자세한 내용은 VPC 문서의 라우팅 순서를 참조하세요.

기본 우선순위 및 MED

Cloud Router는 피어 라우터에서 공지된 MED 값을 사용하여 기본 우선순위를 계산합니다.

  • 대상 프리픽스의 MED 값이 0에서 231 -1(포함) 사이인 경우 Cloud Router는 기본 우선순위를 MED 값으로 설정합니다.
  • 대상 프리픽스의 MED 값이 231 232 -1(포함) 사이이면 Cloud Router는 기본 우선순위를 231 -1로 설정합니다.

Cloud Router가 VPC 네트워크의 커스텀 동적 경로를 만들 때 설정하는 최종 우선순위 값은 네트워크의 동적 라우팅 모드에 따라 다릅니다. 자세한 내용은 동적 라우팅 모드의 효과를 참조하세요.

정적 경로

인스턴스가 패킷을 전송하면 Google Cloud는 라우팅 순서에 따라 적용 가능한 경로 집합에서 하나의 경로를 선택하려고 시도합니다. 자세한 내용은 VPC 문서의 라우팅 순서 섹션을 참조하세요.

겹치는 IP 범위

IP 범위가 겹치는 VPC 서브넷 및 온프레미스 경로 공지가 있는 경우 Google Cloud는 IP 범위에 따라 이그레스 트래픽을 전달합니다.

자세한 내용은 VPC 문서의 적용 가능한 경로를 참조하세요.

한 BGP 세션에서 학습된 경로를 다른 BGP 세션으로 공지

Cloud Router는 현재 정적 경로 공지를 통해 한 BGP 세션에서 학습된 온프레미스 경로를 다른 BGP 세션으로 공지하는 것을 지원하지 않습니다. 이를 시도하면 경로가 삭제될 수 있습니다.

동적 경로를 여러 VPC 네트워크와 올바르게 교환하는 방법에 대한 자세한 내용은 Cloud Router 문제해결 페이지에서 일부 온프레미스 IP 프리픽스를 사용할 수 없음을 참조하세요.

학습된 경로의 한도

학습된 경로에는 두 가지 한도가 있습니다. 이러한 한도는 학습된 경로의 최대 개수를 직접 정의하지 않습니다. 대신 고유 대상 프리픽스의 최대 개수를 정의합니다. 이러한 한도에 대한 자세한 내용은 한도를 참조하세요.

이러한 한도의 사용량을 모니터링하려면 다음 측정항목을 사용합니다.

  • router.googleapis.com/dynamic_routes/learned_routes/used_unique_destinations
  • router.googleapis.com/dynamic_routes/learned_routes/unique_destinations_limit
  • router.googleapis.com/dynamic_routes/learned_routes/any_dropped_unique_destinations

이러한 한도와 관련된 로그 메시지, 이를 모니터링하는 데 사용할 수 있는 측정항목, 문제 해결 방법에 대한 자세한 내용은 문제 해결 페이지의 할당량 및 한도 확인을 참조하세요.

공지된 프리픽스 및 우선순위

Cloud Router는 BGP 피어에 프리픽스를 공지할 때 공지의 각 프리픽스에 대한 우선순위를 포함합니다 (BGP 메시지). 공지된 우선순위는 MED로 구현됩니다.

모든 또는 일부 BGP 세션에 Cloud Router가 공지하는 프리픽스를 제어할 수 있습니다. 프리픽스의 기본 우선순위를 정의하여 공지된 우선순위(MED)을 제어합니다.

  • VPC 네트워크가 리전 동적 라우팅 모드를 사용하는 경우 커스텀 범위를 공지하지 않는 한, 각 Cloud Router는 Cloud Router와 동일한 리전의 서브넷 범위만 공지합니다. 각 범위는 MED가 기본 우선순위인 프리픽스로 공지됩니다.

  • VPC 네트워크가 전역 동적 라우팅 모드를 사용하는 경우 커스텀 범위를 공지하지 않는 한, 각 Cloud Router는 MED가 기본 우선순위와 일치하는 프리픽스로 로컬 리전의 서브넷 범위를 공지합니다. 또한 Cloud Router는 다른 리전의 서브넷 범위를 MED가 기본 우선순위와 리전 간 비용 비용을 더한 것과 같은 프리픽스로 공지합니다. Google Cloud는 네트워크 성능, 거리, 리전 간 사용 가능한 대역폭과 같은 요소를 기반으로 리전 간 비용을 자동으로 계산합니다. 각 리전 간 비용은 서브넷의 리전과 공지하는 Cloud Router의 리전이라는 두 리전 쌍에 고유한 값을 갖습니다.

온프레미스 라우터가 공지 프리픽스와 우선순위를 수신하면 VPC 네트워크로 패킷을 전송하는 데 사용되는 경로를 만듭니다.

기본 우선순위 안내

Cloud Router에서 BGP 세션을 구성할 때 BGP 세션의 기본 공지 우선순위를 지정할 수 있습니다. 기본 공지 우선순위는 해당 BGP 세션에서 공지하는 모든 프리픽스 (대상)에 적용됩니다.

기본 우선순위는 0부터 65535까지의 정수입니다. 가능한 가장 높은 기본 우선순위는 0입니다. 기본 우선순위 기본값은 100입니다. 기본 우선순위를 지정하지 않으면 우선순위 기본값이 사용됩니다.

기본 우선순위를 사용하면 온프레미스 시스템에서 VPC 네트워크로 패킷을 전송하는 데 사용할 Cloud VPN 터널 또는 VLAN 연결을 제어할 수 있습니다. 기본 우선순위를 사용하여 활성/활성, 활성/수동, 또는 이러한 토폴로지의 커스텀 조합을 만들 수 있습니다. HA VPN 터널을 사용하는 예시는 Cloud VPN 문서의 HA VPN의 활성/활성 및 활성/수동 라우팅 옵션을 참조하세요.

기본 우선순위를 선택할 때는 다음 사항에 유의하세요.

  • 리전 간 비용은 201 이상 9999 이하입니다. 이 값은 두 리전 간의 거리, 지연 시간 및 기타 요소에 따라 다릅니다. Google에서 리전 간 비용 값을 생성하므로 사용자는 이를 수정할 수 없습니다.

  • 리전 내 Cloud Router 간의 BGP 세션에 대한 기본 우선순위는 0이상 200이하여야 합니다. 리전 간 비용은 최소 201 이상이어야 하므로 기본 우선순위를 201 이상으로 사용하는 경우에는 Cloud VPN 터널 또는 VLAN 연결에 의도했던 것 보다 낮은 우선순위를 잘못 할당할 수 있습니다. 다른 리전의 다른 BGP 세션에서는 종합적으로 더 높은 우선순위(MED가 기본 우선순위와 리전 간 비용을 더한 값)를 갖는 동일한 프리픽스를 공지할 수도 있습니다. 다른 리전에서 기본 우선순위를 신중하게 설정하지 않으면 예기치 않은 Cloud VPN 터널 또는 VLAN 연결로 인해 온프레미스 트래픽이 VPC 네트워크로 전달될 수 있습니다.

  • 10,200 이상의 기본 우선순위는 프리픽스의 전체 공지 우선순위 (MED, 기본 우선순위 + 리전 간 비용)가 기본 우선순위가 200 이하인 다른 공지된 프리픽스보다 항상 낮다는 것을 보장합니다.

기본 우선순위를 설정하는 방법에 대한 자세한 내용은 기본 공지 경로 우선순위 업데이트를 참조하세요.

예시

이 섹션에서는 전역 동적 라우팅을 사용할 때 리전 간 비용이 공지된 MED에 어떻게 영향을 미치는지 보여주는 예시를 제공합니다.

활성/활성 터널이 있는 HA VPN

이 예시에서는 다음이 포함된 VPC 네트워크가 있습니다.

  • 다음의 리전 us-central1, europe-west1, us-west-1에 각각 한 개의 서브넷
  • us-central1에서 두 개의 HA VPN 터널에 대해 두 개의 BGP 세션을 관리하는 한 개의 Cloud Router
  • us-west1에서 두 개의 HA VPN 터널에 대해 두 개의 BGP 세션을 관리하는 한 개의 Cloud Router

이 예시를 설명하기 위해 리전 간 비용 예시가 포함된 다음 다이어그램을 참조하세요.

활성/활성 터널이 있는 HA VPN
활성/활성 터널이 있는 HA VPN (확대하려면 클릭)

각 BGP 세션의 기본 우선순위 기본값은 100라고 가정합니다.

다음 표는 온프레미스 우선순위에서 각 서브넷으로 가는 트래픽의 공지된 MED 값을 계산하기 위해 기본 우선순위 및 리전 간 비용을 사용하는 방법을 보여줍니다.

10.0.1.0/24 (us-central1)

이 테이블은 us-central1에 있는 서브넷 IP 주소 범위 10.0.1.0/24를 공지하는 BGP 세션을 보여줍니다.

온프레미스 네트워크의 트래픽은 BGP 세션의 공지된 MED가 가장 낮으므로 us-central1에서 HA VPN을 사용합니다.

VPN 터널 기본 우선순위 리전 간 비용 공지된 MED 경로 순위
central-tunnel-0,
central-tunnel-1
100 0 100 첫 번째 선택
west-tunnel-0,
west-tunnel-1
100 250 350 두 번째 선택

10.0.2.0/24 (europe-west1)

이 테이블은 europe-west1에 있는 서브넷 IP 주소 범위 10.0.2.0/24를 공지하는 BGP 세션을 보여줍니다.

온프레미스 네트워크의 트래픽은 BGP 세션의 공지된 MED가 가장 낮으므로 us-central1에서 HA VPN을 사용합니다.

VPN 터널 기본 우선순위 리전 간 비용 공지된 MED 경로 순위
central-tunnel-0,
central-tunnel-1
100 300 400 첫 번째 선택
west-tunnel-0,
west-tunnel-1
100 350 450 두 번째 선택

10.0.3.0/24 (us-west1)

이 테이블은 us-west1에 있는 서브넷 IP 주소 범위 10.0.3.0/24를 공지하는 BGP 세션을 보여줍니다.

온프레미스 네트워크의 트래픽은 BGP 세션의 공지된 MED가 가장 낮으므로 us-west1에서 HA VPN을 사용합니다.

VPN 터널 기본 우선순위 리전 간 비용 공지된 MED 경로 순위
central-tunnel-0,
central-tunnel-1
100 250 350 두 번째 선택
west-tunnel-0,
west-tunnel-1
100 0 100 첫 번째 선택

활성/수동 터널이 있는 HA VPN

이 예시에서는 이전 예시와 동일하지만 각 리전의 활성/수동 HA VPN 터널 쌍을 달성하기 위해 기본 우선순위가 수정된 토폴로지를 사용합니다.

  • BGP 세션의 기본 우선순위 기본값이 100인 기본 터널
  • BGP 세션의 낮은 우선순위가 351인 보조 터널

다음 표는 온프레미스 우선순위에서 각 서브넷으로 가는 트래픽의 공지된 MED 값을 계산하기 위해 기본 우선순위 및 리전 간 비용을 사용하는 방법을 보여줍니다.

10.0.1.0/24 (us-central1)

이 테이블은 us-central1에 있는 서브넷 IP 주소 범위 10.0.1.0/24를 공지하는 BGP 세션을 보여줍니다.

온프레미스 네트워크의 트래픽은 BGP 세션의 공지된 MED가 가장 낮으므로 us-central1에서 기본 VPN 터널을 사용합니다. 해당 터널을 사용할 수 없다면 트래픽은 us-west1의 기본 터널을 사용합니다.

VPN 터널 기본 우선순위 리전 간 비용 공지된 MED 경로 순위
central-tunnel-0 100 0 100 첫 번째 선택
central-tunnel-1 351 0 351 세 번째 선택
west-tunnel-0 100 250 350 두 번째 선택
west-tunnel-1 351 250 601 네 번째 선택

10.0.2.0/24 (europe-west1)

이 테이블은 europe-west1에 있는 서브넷 IP 주소 범위 10.0.2.0/24를 공지하는 BGP 세션을 보여줍니다.

온프레미스 네트워크의 트래픽은 BGP 세션의 공지된 MED가 가장 낮으므로 us-central1에서 기본 VPN 터널을 사용합니다. 해당 터널을 사용할 수 없다면 트래픽은 us-west1의 기본 터널을 사용합니다.

VPN 터널 기본 우선순위 리전 간 비용 공지된 MED 경로 순위
central-tunnel-0 100 300 400 첫 번째 선택
central-tunnel-1 351 300 651 세 번째 선택
west-tunnel-0 100 350 450 두 번째 선택
west-tunnel-1 351 350 701 네 번째 선택

10.0.3.0/24 (us-west1)

이 테이블은 us-west1에 있는 서브넷 IP 주소 범위 10.0.3.0/24를 공지하는 BGP 세션을 보여줍니다.

온프레미스 네트워크의 트래픽은 BGP 세션의 공지된 MED가 가장 낮으므로 us-west1에서 기본 VPN 터널을 사용합니다. 해당 터널을 사용할 수 없다면 트래픽은 us-central1의 기본 터널을 사용합니다.

VPN 터널 기본 우선순위 리전 간 비용 공지된 MED 경로 순위
central-tunnel-0 100 250 350 두 번째 선택
central-tunnel-1 351 250 601 네 번째 선택
west-tunnel-0 100 0 100 첫 번째 선택
west-tunnel-1 351 0 351 세 번째 선택

전 세계적으로 선호하는 Dedicated Interconnect

이 예시는 us-west1 리전의 Cloud VPN 터널 2개를 VLAN 연결 2개로 교체한다는 점을 제외하면 위의 예시와 유사합니다.

이 예시를 보려면 다음 다이어그램을 참조하세요.

전 세계적으로 선호하는 Dedicated Interconnect
전 세계적으로 선호하는 Dedicated Interconnect (확대하려면 클릭)

VLAN 연결의 우선순위를 지정하고자 합니다. us-central1 리전의 HA VPN 터널에 더 큰 기본 우선순위를 지정하여 우선순위를 낮춥니다.

다음 표는 온프레미스 우선순위에서 각 서브넷으로 가는 트래픽의 공지된 MED 값을 계산하기 위해 기본 우선순위 및 리전 간 비용을 사용하는 방법을 보여줍니다.

10.0.1.0/24 (us-central1)

이 테이블은 us-central1에 있는 서브넷 IP 주소 범위 10.0.1.0/24를 공지하는 BGP 세션을 보여줍니다.

온프레미스 네트워크의 트래픽은 BGP 세션의 공지된 MED가 가장 낮으므로 us-west1에서 VLAN 연결을 사용합니다.

VPN 터널 또는 VLAN 연결 기본 우선순위 리전 간 비용 공지된 MED 경로 순위
central-tunnel-0,
central-tunnel-1
351 0 351 두 번째 선택
west-attachment-0,
west-attachment-1
100 250 350 첫 번째 선택

10.0.2.0/24 (europe-west1)

이 테이블은 europe-west1에 있는 서브넷 IP 주소 범위 10.0.2.0/24를 공지하는 BGP 세션을 보여줍니다.

온프레미스 네트워크의 트래픽은 BGP 세션의 공지된 MED가 가장 낮으므로 us-west1에서 VLAN 연결을 사용합니다.

VPN 터널 또는 VLAN 연결 기본 우선순위 리전 간 비용 공지된 MED 경로 순위
central-tunnel-0,
central-tunnel-1
351 300 651 두 번째 선택
west-attachment-0,
west-attachment-1
100 350 450 첫 번째 선택

10.0.3.0/24 (us-west1)

이 테이블은 us-west1에 있는 서브넷 IP 주소 범위 10.0.3.0/24를 공지하는 BGP 세션을 보여줍니다.

온프레미스 네트워크의 트래픽은 BGP 세션의 공지된 MED가 가장 낮으므로 us-west1에서 VLAN 연결을 사용합니다.

VPN 터널 또는 VLAN 연결 기본 우선순위 리전 간 비용 공지된 MED 경로 순위
central-tunnel-0,
central-tunnel-1
351 250 601 두 번째 선택
west-attachment-0,
west-attachment-1
100 0 100 첫 번째 선택

기본 경로

특정 IP 대상에 지정된 경로가 없으면 다른 옵션이 없을 때 마지막 수단으로 사용되는 기본 경로로 트래픽이 전송됩니다. 예를 들어 Google Cloud VPC 네트워크에는 트래픽을 인터넷 게이트웨이로 전송하는 기본 경로(0.0.0.0/0)가 자동으로 포함됩니다.

경우에 따라 기본적으로 온프레미스 네트워크로 트래픽을 전달하는 것이 좋습니다. 그러려면 온프레미스 라우터에서 Cloud Router로 기본 경로를 공지하면 됩니다. Cloud Router를 사용하면 정적 경로를 만들고 관리할 필요가 없습니다. 온프레미스 네트워크에서 기본 경로를 공지하는 경우 자동으로 생성되는 다른 기본 경로(MED 값이 더 낮음)보다 우선순위가 높은지 확인하세요. 경로 페이지로 이동하고 대상 IP 범위에서 0.0.0.0/0인 경로의 우선순위를 확인한 후 다음 홉에서 Default internet gateway를 확인합니다.

단계적 재시작

Cloud Router에서는 온프레미스 라우터에서 전송된 단계적 재시작 메시지를 반영합니다. 온프레미스 라우터를 단계적으로 재시작하도록 구성한 경우 라우터에서 소프트웨어 업데이트를 설치하거나 정기적인 유지보수를 수행할 때마다 Cloud Router에 알림을 보낼 수 있습니다. Cloud Router는 온프레미스 라우터의 단계적 재시작 타이머 설정에서 정의된 시간 동안 온프레미스 라우터에서 학습한 커스텀 동적 경로를 유지합니다.

단계적 재시작 타이머에 대한 자세한 내용은 BGP 타이머 설정을 참조하세요.

BGP 타이머 설정

Cloud Router와 온프레미스 라우터는 다음과 같은 타이머 설정을 사용하여 통신을 유지합니다.

연결 유지 타이머
Cloud Router와 해당 온프레미스 피어 라우터 간에 교환되는 정기적인 BGP 하트비트의 간격입니다. 보류 타이머와 마찬가지로, 다른 라우터에 대한 각 라우터의 사용 가능 여부를 나타냅니다. 온프레미스 라우터에서 연결 유지 타이머를 20초로 설정합니다.
보류 타이머
이 타이머는 마지막으로 성공한 연결 유지 하트비트가 감지된 이후 대기하는 최소 시간을 추적하며, Cloud Router 또는 온프레미스 라우터가 다른 라우터에서 학습한 경로를 삭제할 때까지 대기해야 하는 시간을 나타냅니다. 온프레미스 라우터에서 보류 타이머를 60초로 설정합니다.
단계적 재시작 타이머

온프레미스 라우터가 새로운 연결 유지 하트비트를 예상하기 전에 해당 Cloud Router에서 단계적 재시작 알림 메시지를 수신한 후 정기적인 연결 유지 하트비트 없이 대기하는 시간입니다. 새로운 연결 유지 하트비트가 수신되지 않으면 온프레미스 라우터는 Cloud Router에서 학습한 경로를 삭제합니다.

Cloud Router는 이 값을 1초로 설정합니다. 온프레미스 라우터의 경우 단계적 재시작 타이머를 필요에 맞는 값으로 설정합니다. 각 라우터는 BGP 세션을 설정할 때 OPEN 메시지를 통해 단계적 재시작 타이머 값을 피어에 전달합니다.

다음 홉 Cloud VPN 터널이 다운되었거나 Cloud Interconnect 연결이 다운된 것으로 확인되면 Cloud Router는 온프레미스 기기에서 학습한 커스텀 동적 경로를 철회합니다.

비활성 경로 타이머

이 설정은 라우터가 다른 라우터에서 End-Of-Record(EOR) 메시지를 수신한 후 학습된 경로를 삭제할 때까지 대기하는 시간을 지정합니다. 이 타이머는 단계적 재시작 후 BGP 세션이 다시 초기화될 때 시작되지만, 문제의 프리픽스는 UPDATE 메시지로 해결되지 않습니다. Cloud Router의 설정과 일치하도록 온프레미스 라우터에서 비활성 경로 타이머를 300초로 설정하는 것이 좋습니다.

중복 Cloud VPN 터널

온프레미스 게이트웨이가 단계적 재시작을 지원하지 않는 경우 BGP 세션의 어느 한쪽에서 장애가 발생하면 세션이 실패하고 트래픽이 중단됩니다. BGP 시간 제한(Cloud Router의 경우 60초)이 초과되면 양쪽에서 경로가 철회됩니다. 동적으로 라우팅된 Cloud VPN 트래픽이 더 이상 터널로 들어가지 않습니다. 터널의 정적 경로는 계속 서비스됩니다.

단계적 재시작이 지원되지 않을 경우 터널을 하나씩 사용하는 온프레미스 게이트웨이를 두 개 배포하면 중복화와 장애 조치가 제공됩니다. 이 구성을 사용하면 트래픽을 중단하지 않고 하나의 터널과 기기를 오프라인으로 전환하여 소프트웨어 업그레이드 또는 유지관리를 수행할 수 있습니다. 또한 하나의 터널에 장애가 발생하면 다른 터널이 경로를 활성 상태로 유지하므로 트래픽 흐름이 유지됩니다.

업그레이드 주기

Cloud Router는 주기적으로 업그레이드되며 업그레이드는 60초 안에 완료됩니다. 업그레이드 중에는 Cloud Router를 사용할 수 없습니다. BGP 보류 타이머는 피어링된 BGP 라우터를 사용할 수 없을 때 학습된 경로가 보존되는 기간을 결정합니다. BGP 보류 타이머는 양쪽의 두 값 중 작은 값을 선택합니다. Cloud Router는 BGP 보류 타이머에 60초 값을 사용합니다. 피어 BGP 보류 타이머를 60초 이상으로 설정하는 것이 좋습니다(기본값은 3분). 그러면 두 라우터가 업그레이드 중에 경로를 보존하고 트래픽이 계속 흐릅니다.

단일 Cloud VPN 게이트웨이에 대한 Cloud VPN 게이트웨이 유지보수 주기 중에 Cloud Router를 사용하면 BGP 세션이 재설정되고, 경로를 다시 학습해야 하므로 터널 복구 시간에 약 20초가 추가됩니다. Cloud VPN 게이트웨이 복구 시간은 일반적으로 약 1분입니다. 중복 Cloud VPN 게이트웨이가 있는 경우 한 번에 Cloud VPN 게이트웨이 하나만 중지되므로 트래픽은 영향을 받지 않습니다.

BGP 라우터 ID 및 BGP 세션 다시 시작

Cloud Router는 BGP 라우터 ID로 가장 높은 인터페이스 IP 주소를 선택하며, 해당 주소를 사용할 수 있는 한 이 ID를 유지합니다. BGP 라우터 ID에 사용 중인 Cloud Router 인터페이스를 삭제하면 Cloud Router가 새 라우터 ID를 선택해야 합니다. 그러면 모든 BGP 세션이 다시 시작됩니다. 또한 주기적 유지보수를 위해 Cloud Router가 다시 시작되는 경우에도 라우터 ID가 변경될 수 있습니다.

추가 리소스

지원되는 서비스에서 정적 및 동적 라우팅을 사용하는 방법에 대한 자세한 내용은 다음 문서를 참조하세요.

제품 라우팅 문서
전용 상호 연결 정적 지원되지 않음
전용 상호 연결 동적 VLAN 연결 만들기
기본 VPN 정책 기반, 정적 정적 라우팅을 사용하여 기본 VPN 만들기
기본 VPN 또는 HA VPN 동적 동적 라우팅을 사용하여 기본 VPN 만들기
HA VPN 게이트웨이 - 피어 VPN 게이트웨이 만들기
Google Cloud 네트워크 간에 HA VPN 만들기

다음 단계

  • 네트워크 토폴로지를 빌드하려면 Cloud Router 권장사항을 참조하세요.
  • Cloud Router 용어에 대한 정의를 보려면 주요 용어를 참조하세요.
  • Cloud Router 사용 시 문제를 해결하려면 문제 해결을 참조하세요.