MCR Peering entre clouds privadas
Megaport Cloud Router (MCR) oferece suporte a multicloudO uso de múltiplos serviços de computação em nuvem em uma única arquitetura heterogênea. Por exemplo, uma empresa pode usar vários provedores de nuvem para serviços de infraestrutura (IaaS) e de software (SaaS). Uma das principais propostas de valor da Megaport é viabilizar a conectividade multicloud.
arquiteturas que incluem combinações de tipos de peering de cloud privada e pública, bem como conectividade fora da cloud com seu data center. Este tópico descreve:
- As opções de conectividade do MCR com suporte pelos provedores de serviços de cloud (CSPs) para peering entre clouds privadas.
- Como os números de sistema autônomo (ASNs) funcionam com o Border Gateway Protocol (BGP) para anunciar rotas.
Opções de conectividade com suporte no MCR
MCR permite criar uma arquitetura robusta que suporta peering privado com vários provedores de cloud. Você pode fornecer conectividade ao mesmo provedor de cloud, em diferentes regiões, com on-ramps diferentes, desde que cada peer BGP tenha um ASN diferente.
Esta seção descreve muitas, mas não todas, as arquiteturas de conectividade de peering privado com suporte no MCR. Como as redes não são idênticas, os exemplos fornecem um ponto de partida para a sua arquitetura de peering.
Peering privado da AWS entre VPCs
A AWS oferece a capacidade de rotear entre diferentes AWS Virtual Private Clouds (VPCs) ao usar seu próprio ASN privado e o MCR.
Peering privado do Azure com um único ExpressRoute e várias VNets
Com o Azure, é possível anexar várias virtual networks (VNets) ao mesmo ExpressRoute e rotear o tráfego entre as VNets sem sair da rede do Azure.
Nota
Peering privado do Azure com ExpressRoute em dupla não é compatível. Nesse cenário, a prevenção de loop do BGP impedirá que as rotas sejam anunciadas, porque o Azure detectará seu próprio ASN no caminho AS.
Peering privado do Azure com ExpressRoute duplo e roteamento inter-VNet
MCR é compatível com uma arquitetura com dois circuitos ExpressRoute conectando cada VNet a ambos os circuitos ExpressRoute. Como o roteamento inter-VNet ocorre sem sair do Azure, o caminho AS não é avaliado. Essa implementação oferece alta disponibilidade e também permite o roteamento inter-VNet.
Peering de VPC na Google Cloud Platform
As VPCs na Google Cloud Platform (GCP) são globais e incluem sub-redes para cada região. A GCP oferece a capacidade de realizar peering de VPC para rotear o tráfego entre duas VPCs.
Peering de VCN do Oracle Cloud Infrastructure
A Oracle oferece peering remoto de Virtual Cloud Network (VCN) para rotear entre regiões. O suporte inclui o roteamento entre Oracle Cloud Infrastructure (OCI) e OCI Classic, ou entre OCI e Oracle Government Cloud.
Nota
O roteamento externo entre regiões comerciais da OCI não é compatível.
Para mais informações, consulte Remote VCN Peering.
Entendendo os números de sistema autônomo
Um sistema autônomo (AS) é uma única rede ou um conjunto de redes e roteadores que são gerenciados e supervisionados em nome de uma única entidade administrativa, como uma divisão de negócios. É atribuído a um AS um número globalmente exclusivo que identifica a rede para o mundo.
O MCR usa BGP para trocar rotas entre peering privado e tipos de peering fora da cloud. Para reduzir a complexidade do suporte ao BGP para os CSPs, o MCR fornece configuração automatizada e segue políticas padrão de roteamento BGP e melhores práticas de roteamento inter-AS. Embora o MCR siga as melhores práticas de roteamento e o BGP tenha prevenção de loop incorporada, entender a lista de caminho AS é útil ao atribuir ASNs aos peers.
Entendendo a prevenção de loop do caminho AS
Quando rotas são anunciadas para um vizinho BGP externo (eBGP), o ASN do roteador local é adicionado à lista de caminho AS (AS_PATH). Para o sistema autônomo (AS) receptor, isso cria um rastro até o AS de origem. Esta imagem mostra dois roteadores, R2 e R3, com o mesmo ASN:
Quando um peer eBGP recebe uma rota eBGP que inclui seu próprio número AS no caminho AS, ele descartará a rota para evitar um loop de rota BGP. Esse é o comportamento esperado com o BGP. Nesse cenário, como R2 e R3 têm o mesmo ASN, o R3 descartará as rotas do R2 ao recebê-las.
Após atualizar a configuração do R2 com um número AS exclusivo, 64515, o R3 agora aceita as rotas anunciadas pelo R2. É importante ter isso em mente ao configurar peering entre duas clouds privadas.
Suporte a ASN privado
Com o AWS Direct Connect gateway, você pode levar seu próprio ASN privado para o lado da Amazon da conexão. Outros provedores de serviços de cloud exigem que você faça peering usando o ASN público deles.
Esta tabela resume os ASNs com suporte de cada CSP:
| Provedor de cloud | Tipo de Peering | AS do lado do cliente | AS do lado do provedor de cloud |
|---|---|---|---|
| AWS | PRIV_CLOUD | ASN privado ou público | ASN privado ou ASN 7224 |
| Google Cloud | PRIV_CLOUD | ASN privado ou público | ASN 16550 |
| Oracle Cloud | PRIV_CLOUD | ASN privado ou público | ASN 31898 (Gov Cloud 6142) |
| Microsoft Azure | PRIV_CLOUD | ASN privado ou público | ASN 12076 |
Para saber mais, explore estes recursos.
- AWS – AWS Direct Connect FAQs
- Google Cloud – Establishing 99.99% Availability for Partner Interconnect
- Oracle Cloud – FastConnect Requirements
- Microsoft Azure – Autonomous System numbers (ASN)