Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Como o Cloud Router funciona
O Cloud Router é uma abstração de API implementada por várias tarefas redundantes do BGP, um plano de controle de rota dinâmico e planos de dados e controle de rede de nuvem privada virtual (VPC). Entender como esses três componentes de software funcionam ajuda a entender as operações do Cloud Router e como as opções "learned-route-best-path-selection" funcionam.
Componentes de software do Cloud Router
Há vários componentes de software no Cloud Router e na VPC:
Tarefa do BGP do Cloud Router
As tarefas do BGP do Cloud Router são agrupadas em uma região. Cada tarefa do BGP se comunica com um plano de controle de rota dinâmica para a respectiva região e grupo. As tarefas do BGP não lidam com o processamento de dados de pacotes. Em vez disso, elas gerenciam sessões do BGP para enviar e receber prefixos do BGP.
Plano de controle de rota dinâmica
Cada região contém um plano de controle de rota dinâmica que se comunica com tarefas do BGP para a respectiva região e grupo. No modo de roteamento dinâmico global, os planos de controle de rota dinâmica em uma região também se comunicam com planos de controle de rota dinâmica em outras regiões. Cada plano de controle de rota dinâmica envia mensagens ao plano de controle da rede VPC.
Cada região contém um plano de controle da rede VPC que recebe informações dos grupos de planos de controle de rota dinâmica na própria região. Cada plano de controle de rede VPC programa rotas dinâmicas em redes VPC de recebimento. Os planos de controle de rede VPC também aplicam cotas de rotas dinâmicas.
Plano de dados da rede VPC
Cada região contém um plano de dados da rede VPC que avalia e implementa rotas dinâmicas usando informações do plano de controle da rede VPC. A rede VPC e o plano de dados realiza o encaminhamento de pacotes.
Tarefas do BGP do Cloud Router
A tabela a seguir mostra quantas tarefas do BGP um Cloud Router usa para cenários comuns:
Exemplo de cenário
Número de tarefas do BGP usadas para implementar o Cloud Router
Uma ou mais interfaces, cada uma conectada a um túnel de VPN clássica
Uma tarefa do BGP
Uma ou mais interfaces, cada uma conectada a um anexo da VLAN, em que os
anexos da VLAN estão no mesmo domínio de disponibilidade de borda.
Uma tarefa do BGP
Qualquer número de interfaces, cada uma conectada a um túnel de VPN de alta
disponibilidade, em que todos os túneis estão conectados ao mesmo número de interface
em um ou mais gateways de VPN de alta disponibilidade. Por exemplo, dois túneis, cada um conectado a interface 0 em gateways de VPN de alta disponibilidade diferentes.
Uma tarefa do BGP
Pelo menos duas interfaces, uma conectada a um anexo da VLAN
em um único domínio de disponibilidade de borda, e outra conectada a um
único túnel de VPN de alta disponibilidade, em que os domínios da disponibilidade de
borda e os números da interface do gateway de VPN são iguais. Por exemplo, o primeiro domínio de disponibilidade de borda em um par de domínios de disponibilidade de borda e a primeira interface de gateway de VPN.
Uma tarefa do BGP
Pelo menos duas interfaces, cada uma conectada a uma instância de dispositivo roteador, em que uma das interfaces é configurada como uma interface redundante. Para criar uma interface redundante, use a flag redundant-interface (CLI do Google Cloud) ou o campo redundantInterface (API Compute Engine).
O dispositivo do roteador faz parte do Network Connectivity Center.
Duas tarefas do BGP
Pelo menos duas interfaces, cada uma conectada a um anexo da VLAN, em que os
anexos da VLAN estão em domínios de disponibilidade de borda diferentes.
Duas tarefas do BGP
Pelo menos duas interfaces, cada uma conectada a um
túnel de VPN de alta disponibilidade, em que cada túnel está conectado a interface 0 diferentes
números de interface do gateway da VPN de alta disponibilidade.. Gateway e outro túnel conectado a interface 1 do mesmo gateway ou de um gateway diferente.
Duas tarefas do BGP
Um Cloud Router com pelo menos o seguinte:
Uma interface conectada a um anexo da VLAN em edge availability domain 0 e/ou uma interface conectada a um túnel de VPN de alta disponibilidade que está conectada a interface 0 de um gateway de VPN de alta disponibilidade.
Uma interface conectada a um anexo da VLAN em edge availability domain 1 e/ou uma interface conectada a um túnel de VPN de alta disponibilidade conectado a interface 1 de um gateway de VPN de alta disponibilidade.
Uma interface conectada a um túnel de VPN clássica.
Três tarefas do BGP
Manutenção de software
O Google Cloud realiza eventos de manutenção regulares para lançar novos recursos e melhorar a confiabilidade. Durante a manutenção, novas tarefas do BGP assumem o controle do BGP como locutores e agentes de resposta.
A manutenção do Cloud Router é um processo automático e foi projetada para que não interrompa o roteamento. Espera-se que os eventos de manutenção levem mais de 60 segundos. Antes da manutenção, o Cloud Router envia uma notificação de reinicialização normal (um pacote TCP FIN) para o roteador local.
Se o roteador local puder processar eventos de reinicialização normal, ele registrará
um evento de reinicialização normal durante a manutenção do Cloud Router. Para roteadores locais não compatíveis com a reinicialização informada, verifique se o temporizador de espera do roteador local está definido para 60 segundos.
O temporizador de espera do BGP determina o tempo durante o qual as rotas coletadas são preservadas quando o roteador BGP de mesmo nível não está disponível. Esse temporizador assume o menor valor nos dois lados. O Cloud Router usa um valor padrão de 60 segundos para o temporizador de espera do BGP. Recomendamos que você defina o temporizador de espera do BGP no roteador local para 60 segundos ou mais. Assim, os dois roteadores preservarão as respectivas rotas durante esses upgrades, e o tráfego continuará fluindo. Para mais informações, consulte Como gerenciar timers do BGP.
Os eventos de manutenção do Cloud Router não são anunciados com antecedência porque as rotas não são perdidas em roteadores locais configurados corretamente. Para mais informações sobre eventos de manutenção concluídos, consulte Como identificar eventos de manutenção do roteador.
Para saber mais sobre como a reinicialização normal funciona com a detecção de encaminhamento bidirecional (BFD, na sigla em inglês), consulte Reinicialização otimizada e BFD.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-12-05 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)."]]
