Cloud Router는 중복된 여러 BGP 태스크, 동적 경로 컨트롤 플레인, 가상 프라이빗 클라우드(VPC) 네트워크 제어 및 데이터 영역으로 구현된 API 추상화입니다. 이 세 가지 소프트웨어 구성요소가 함께 작동하는 방식을 이해하면 Cloud Router 작업과 learned-route-best-path-selection 옵션의 작동 방식을 이해하는 데 도움이 됩니다.
Cloud Router의 소프트웨어 구성요소
Cloud Router 및 VPC에는 여러 소프트웨어 구성요소가 있습니다.
Cloud Router BGP 태스크
Cloud Router BGP 태스크는 리전 내에서 그룹화됩니다. 각 BGP 태스크는 리전 및 그룹의 동적 경로 컨트롤 플레인과 통신합니다. BGP 태스크는 패킷 데이터 처리를 취급하지 않습니다. 대신 BGP 태스크가 BGP 세션을 관리하여 BGP 프리픽스를 전송하고 수신합니다.
동적 경로 컨트롤 플레인
각 리전에는 리전 및 그룹의 BGP 태스크와 통신하는 동적 경로 컨트롤 플레인이 포함되어 있습니다. 전역 동적 라우팅 모드에서 한 리전의 동적 경로 컨트롤 플레인은 다른 리전의 동적 경로 컨트롤 플레인과도 통신합니다. 각 동적 경로 컨트롤 플레인은 VPC 네트워크 컨트롤 플레인에 메시지를 전송합니다.
각 리전에는 자체 리전의 동적 경로 컨트롤 플레인 그룹에서 정보를 수신하는 VPC 네트워크 컨트롤 플레인이 포함되어 있습니다. 각 VPC 네트워크 컨트롤 플레인은 수신 VPC 네트워크에서 동적 경로를 프로그래밍합니다. VPC 네트워크 컨트롤 플레인도 동적 경로 할당량을 적용합니다.
VPC 네트워크 데이터 영역
각 리전에는 VPC 네트워크 컨트롤 플레인의 정보를 사용하여 동적 경로를 평가하고 구현하는 VPC 네트워크 데이터 영역이 포함되어 있습니다. VPC 네트워크 데이터 영역은 패킷 전달을 실행합니다.
Cloud Router BGP 태스크
다음 표에서는 Cloud Router가 일반적인 시나리오에 사용하는 BGP 태스크 수를 보여줍니다.
예시 시나리오
Cloud Router를 구현하는 데 사용되는 BGP 태스크 수
각각 기본 VPN 터널에 연결된 하나 이상의 인터페이스
BGP 태스크 1개
VLAN 연결이 동일한 에지 가용성 도메인에 있는 VLAN 연결에 연결된 하나 이상의 인터페이스
BGP 태스크 1개
터널이 모두 하나 이상의 HA VPN 게이트웨이의 동일한 인터페이스 번호로 연결된 HA VPN 터널에 연결된 인터페이스 수(예: 여러 HA VPN 게이트웨이의 interface 0에 연결된 2개의 터널).
BGP 태스크 1개
인터페이스 2개 이상(한 개의 인터페이스는 단일 에지 가용성 도메인의 VLAN 연결에 연결되고 다른 한 개의 인터페이스는 에지 가용성 도메인과 VPN 게이트웨이 인터페이스 번호가 동일한 단일 HA VPN 터널에 연결됨).(예: 에지 가용성 도메인과 첫 번째 VPN 게이트웨이 인터페이스 페어의 첫 번째 에지 가용성 도메인)
BGP 태스크 1개
적어도 두 개의 인터페이스로 각각 라우터 어플라이언스 인스턴스에 연결되어 있으며, 이 때 인터페이스 중 하나가 중복 인터페이스로 구성됩니다. 중복 인터페이스를 만들려면 redundant-interface 플래그(Google Cloud CLI)나 redundantInterface 필드(Compute Engine API)를 사용합니다.
라우터 어플라이언스는 Network Connectivity Center의 일부입니다.
BGP 태스크 2개
VLAN 연결이 서로 다른 에지 가용성 도메인에 있는 VLAN 연결에 연결된 2개 이상의 인터페이스
BGP 태스크 2개
HA VPN 터널에 연결된 2개 이상의 인터페이스. 각 터널은 서로 다른 HA VPN 게이트웨이 인터페이스 번호에 연결됩니다(예: 한 터널은 HA VPN 게이트웨이의 interface 0에 연결되고 다른 터널은 동일한 게이트웨이 또는 다른 게이트웨이의 interface 1에 연결).
BGP 태스크 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개
BGP 태스크 3개
소프트웨어 유지관리
Google Cloud 는 새로운 기능을 출시하고 안정성을 개선하기 위해 정기적인 유지보수 이벤트를 실행합니다. 유지보수 중에는 새 BGP 태스크가 BGP 스피커 및 응답자로 전환됩니다.
Cloud Router 유지보수는 자동 프로세스이며, 라우팅이 중단되지 않도록 설계되었습니다. 유지보수 이벤트는 최대 120초를 넘기지 않습니다. 유지보수 전에 Cloud Router는 단계적 재시작 알림(TCP FIN 패킷)을 온프레미스 라우터에 전송합니다.
온프레미스 라우터에서 단계적 재시작 이벤트를 처리할 수 있으면 Cloud Router 유지보수 중에 단계적 재시작 이벤트를 로깅합니다.
Cloud Router 유지보수 이벤트는 단계적 재시작을 지원하는 제대로 구성된 온프레미스 라우터에서 경로가 손실되지 않으므로 미리 공지되지 않습니다. 완료된 유지보수 이벤트에 대한 자세한 내용은 라우터 유지보수 이벤트 식별을 참고하세요.
단계적 재시작이 양방향 전송 감지(BFD)에서 작동하는 방식에 대한 자세한 내용은 단계적 재시작 및 BFD를 참조하세요.
단계적 재시작을 지원하지 않는 온프레미스 라우터의 경우 온프레미스 라우터의 보류 타이머가 60초로 설정되어 있는지 확인합니다. BGP 보류 타이머는 피어링된 BGP 라우터를 사용할 수 없을 때 학습된 경로가 보존되는 기간을 결정합니다.
계획된 유지관리 외에 Cloud Router 작업이 실패하면 Cloud Router와 피어 라우터 간에 BGP 세션이 다시 설정되기 전에 온프레미스 라우터의 보류 타이머가 사용됩니다.
계획된 유지보수의 경우 BGP 유지 시간은 무시됩니다. 대신 Cloud Router는 피어 라우터에 BGP 중지 메시지를 전송하며, 이 메시지는 두 라우터 간에 학습된 경로를 삭제합니다. BGP 타이머에 대한 자세한 내용은 BGP 타이머 관리를 참고하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-31(UTC)"],[],[],null,["# How Cloud Router works\n======================\n\nCloud Router is an API abstraction implemented by multiple and redundant BGP\ntasks, a dynamic route control plane, and Virtual Private Cloud (VPC) network\ncontrol and data planes. Understanding how these three software components work\ntogether helps you understand Cloud Router operations and how\nlearned-route-best-path-selection options work.\n\nSoftware components of Cloud Router\n-----------------------------------\n\nThere are several software components within Cloud Router and\nVPC:\n\nCloud Router BGP task\n: Cloud Router BGP tasks are grouped together within a region. Each\n BGP task communicates with a dynamic route control plane for its region and\n group. BGP tasks don't handle packet data processing. Instead, BGP tasks manage\n BGP sessions to send and receive BGP prefixes.\n\nDynamic route control plane\n: Each region contains a dynamic route control plane that communicates with\n BGP tasks for its region and group. In global dynamic routing mode, dynamic\n route control planes in one region also communicate with dynamic route control\n planes in other regions. Each dynamic route control plane sends messages to the\n VPC network control plane.\n\nVPC network control and data planes\n\n: Google Cloud uses the [Andromeda network virtualization stack (PDF\n download)](https://www.usenix.org/system/files/conference/nsdi18/nsdi18-dalton.pdf)\n as the distributed control and data plane for VPC networking, and\n includes the following components:\n\n VPC network control plane\n : Each region contains a VPC network control plane that\n receives information from the groups of dynamic route control planes in\n their own region. Each VPC network control plane programs\n dynamic routes in receiving VPC networks. VPC\n network control planes also enforce dynamic route quotas.\n\n VPC network data plane\n : Each region contains a VPC network data plane that\n evaluates and implements dynamic routes using information from the\n VPC network control plane. The VPC network\n data plane performs packet forwarding.\n\nCloud Router BGP tasks\n----------------------\n\nThe following table shows how many BGP tasks a Cloud Router uses for\ncommon scenarios:\n\nSoftware maintenance\n--------------------\n\nCloud Router maintenance events release new features and improve\nreliability. During maintenance, new BGP tasks take over as BGP speakers and\nresponders. Before maintenance, the last BGP task notifies its peer router in\none of the following ways:\n\n- If the peer router supports graceful restart, Cloud Router sends a\n graceful restart notification (a TCP `FIN` packet).\n\n- If the peer router *doesn't* support graceful restart, Cloud Router\n sends a BGP `CEASE` notification to the peer router to terminate the BGP\n session.\n\nCloud Router maintenance events aren't announced in advance because\nmaintenance events are automatic and not disruptive, as long as the peer\nrouter supports graceful restart. Maintenance events are designed to complete in\nless than 120 seconds---thus, Cloud Router uses a [120 second\ngraceful restart\ntimer](/network-connectivity/docs/router/how-to/managing-bgp-timers#graceful-restart-timer). For\ninformation about how to find completed maintenance events, see [Identify router\nmaintenance events](/network-connectivity/docs/router/how-to/identifying-router-events).\n\nIf the peer router supports graceful restart, the peer router logs a graceful\nrestart event during Cloud Router maintenance. In accordance with\n[Section 4.2 of RFC\n4724](https://datatracker.ietf.org/doc/html/rfc4724#section-4.2), the peer\nrouter must honor the 120 second Cloud Router graceful restart timer,\npreserving learned routes and continuing to advertise routes, in the event that:\n\n- Cloud Router stops sending BGP keepalive packets.\n\n- *Applicable only when BFD is configured* : Cloud Router stops\n sending BFD packets. Consequently, the peer router *must* honor the BFD\n control plane independent bit value of `0` because Cloud Router\n uses a control plane *dependent* BFD implementation. For more information,\n see [graceful restart and\n BFD](/network-connectivity/docs/router/concepts/bfd#graceful-restart-and-bfd).\n\nIf the peer router *doesn't* support graceful restart or if a peer router has\ngraceful restart disabled, Cloud Router sends a BGP `CEASE`\nnotification following [Section 4.5 of RFC\n4271](https://datatracker.ietf.org/doc/html/rfc4271#section-4.5). After the\n`CEASE` notification, the BGP session remains down until Cloud Router\nreplaces the BGP task. Making adjustments to the Cloud Router hold\ntimer or the peer router hold timer doesn't prevent the BGP session from\nterminating.\n\nPlanned Cloud Interconnect maintenance\n--------------------------------------\n\nFor [planned Cloud Interconnect\nmaintenance](/network-connectivity/docs/interconnect/support/infrastructure-maintenance-events#planned-maintenance),\nCloud Router sends a BGP `CEASE` notification that terminates the BGP\nsession, removing the session's learned and advertised routes. Neither the\ngraceful restart timer nor the negotiated BGP hold timer apply during planned\nmaintenance events.\n\nUnexpected BGP task failures\n----------------------------\n\nCloud Router uses multiple BGP tasks so that HA VPN\ntunnel pairs, Router appliances, and VLAN attachments that meet a\nCloud Interconnect SLA don't depend on a single BGP task. For more\ninformation, see the [Cloud Router BGP tasks](#bgp-tasks) section of\nthis document. If a Cloud Router BGP task fails unexpectedly,\nCloud Router isn't able to send one of the notifications that it\nnormally sends during software maintenance. However, both learned and advertised\nroutes remain for the duration of the negotiated [hold\ntimer](/network-connectivity/docs/router/how-to/managing-bgp-timers#hold_timer)."]]
