Peering Privado na Nuvem com MCR
O Megaport Cloud Router (MCR) suporta arquiteturas multi-cloud que incluem combinações de tipos de peering privado e público, além de conectividade não relacionada à nuvem com seu data center. Este tópico descreve:
- Como os números de sistema autônomo (ASNs) funcionam com o roteamento Border Gateway Protocol (BGP) para anunciar rotas de tráfego.
- As opções de conectividade privada do MCR suportadas pelos Provedores de Serviços em Nuvem (CSPs).
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 por uma única entidade administrativa, como uma divisão de negócios. Um AS recebe um número globalmente exclusivo que identifica a rede para o mundo.
O MCR usa o BGP para trocar rotas de tráfego entre peering privado e tipos de peering não relacionados à nuvem. Para reduzir a complexidade do suporte 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 loops integrada, entender a lista de caminhos do sistema autônomo (AS_PATH) é útil ao atribuir ASNs a peers.
Entendendo a lista de caminhos AS
Quando rotas são anunciadas para um vizinho BGP externo (eBGP), o ASN do roteador local é adicionado à lista de caminhos 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 de AS como um atributo de caminho AS, ele negará a rota e a descartará 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, R3 descartará as rotas de R2 ao recebê-las.
Agora suponha que o R4, com um ASN de 65101, seja adicionado à rede. Nesse cenário, as rotas serão anunciadas de R3 para R4, e de R2 para R4 via R1. No entanto, R3 ainda descartará as rotas de R2 ao recebê-las, pois R2 e R3 têm o mesmo ASN.
Após atualizar a configuração de R2 com um número de AS exclusivo, 64515, R3 agora aceitará as rotas anunciadas por R2.
Suporte a ASN privado
Com o AWS Direct Connect gateway, você pode trazer seu próprio ASN privado para o lado da conexão da Amazon. Outros provedores de serviços em nuvem exigem que você faça o peering usando o ASN público deles.
Esta tabela resume os ASNs suportados por cada CSP:
| Provedor de Nuvem | Tipo de Peering | ASN do Lado do Cliente | ASN do Lado do Provedor de Nuvem |
|---|---|---|---|
| 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 – Estabelecendo 99,99% de disponibilidade para o Partner Interconnect
- Oracle Cloud – Requisitos do FastConnect
- Microsoft Azure – Números de Sistema Autônomo
Opções de conectividade suportadas com o MCR
O MCR permite que você construa uma arquitetura robusta que suporta peering privado com vários provedores de nuvem. Apenas certifique-se de usar ASNs exclusivos entre os peers do MCR, a menos que você esteja criando um peer Border Gateway Protocol interno (iBGP) para outro MCR ou roteador físico no data center. Você pode fornecer conectividade para o mesmo provedor de nuvem, em diferentes regiões, com diferentes on-ramps, desde que não esteja roteando tráfego em um peering eBGP com o mesmo ASN.
Esta seção descreve muitas, mas não todas, as arquiteturas de conectividade de peering privado suportadas com o MCR. Como as redes não são idênticas, os exemplos fornecem um ponto de partida para sua arquitetura de peering.
Peering privado 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 Azure com uma única ExpressRoute e várias VNets
Com o Azure, você pode anexar várias redes virtuais (VNets) à mesma ExpressRoute e rotear o tráfego entre as VNets sem sair da rede Azure.
Aviso
O peering privado Azure com dupla ExpressRoute não é suportado.
Nesse cenário, a prevenção de loops BGP impedirá que as rotas sejam anunciadas, pois o Azure detectará seu próprio ASN na lista de caminhos AS.
Peering privado Azure com dupla ExpressRoute e roteamento inter-VNet
O MCR suporta uma arquitetura com circuitos duplos ExpressRoute conectando cada VNet a ambos os circuitos ExpressRoute. Como o roteamento inter-VNet ocorre sem sair da Azure, o caminho AS não é avaliado. Essa implantação oferece alta disponibilidade, permitindo também o roteamento inter-VNet.
Peering VPC da Google Cloud Platform
As Nuvens Virtuais Privadas (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 VPC para rotear tráfego entre duas VPCs.
Peering VCN da Oracle Cloud Infrastructure
A Oracle oferece peering remoto Virtual Cloud Network (VCN) para rotear entre regiões. O suporte inclui roteamento entre Oracle Cloud Infrastructure (OCI) e OCI Classic, ou entre OCI e Oracle Government Cloud.
Nota
O roteamento externo entre regiões comerciais do OCI não é suportado.
Para mais informações, veja Peering Remoto VCN.