AWS Network: Onde ter duas VPNs, dois DX ou conexões hibridas pode falhar.
Duas conexões pra fora da AWS, com dois Customer Gateways, dois roteadores diferentes, dois pontos de saída apontando pro mesmo VGW. No papel, isso é redundância, já que tem par de tudo, e é um desenho que qualquer time de infra monta pra dormir tranquilo. Contudo existe uma váriavel que faz essa decisão na redundância é efetiva, e não é a quantidade de conexões, e sim a inteligencia de roteamento existente. Nesse artigo vamos entender melhor como o BGP funciona e como ele pode salvar seu final de semana.
Series: AWS Network (3 articles)
- 2AWS Network: Onde ter duas VPNs, dois DX ou conexões hibridas pode falhar. This article
BGP - O protocolo que resistiu
Se você acompanhou o artigo anterior dessa jornada de rede, sobre como a intuição de quem vem do mundo Cisco pode te enganar na AWS, já sabe o fio condutor que ficou plantado lá: na AWS, roteamento não é descoberto, é declarado. Você escreve a rota, ela existe, sem protocolo nenhum decidindo nada por trás.
BGP é a exceção a essa regra, e é exatamente por isso que ele confunde tanta gente. É o único lugar dentro do mundo de redes da AWS onde o caminho volta a ser descoberto de verdade, por protocolo, negociado entre pontas, em vez de digitado por você. Depois de se acostumar que toda rota na AWS é um ato deliberado, ver BGP aparecendo e decidindo caminho sozinho quebra justamente a intuição que você acabou de reconstruir.
Mas vamos começar pelo inicio: o que é o BGP e como ele funciona.
Cada rede tem um dono, e esse dono tem um número
Pensa no correio internacional (sim vou usar o mesmo exemplo do artigo sobre a SWIFT ) Cada país tem seu próprio serviço postal, cuida da própria distribuição interna do jeito que quiser, e decide com quem vai fazer acordo pra trocar correspondência com o resto do mundo. Na internet, esse "país com serviço postal próprio" se chama Sistema Autônomo, ou AS. É qualquer rede que tem administração própria e um número que a identifica de forma única, o ASN (Autonomous System Number).
Sua empresa pode ter um AS, assim como um provedor de internet, e a AWS também aparece do outro lado como um AS sempre que você abre uma sessão BGP com ela, com um ASN próprio (por padrão, 64512, caso você não escolha outro na hora de criar o Virtual Private Gateway). No nosso lab, vamos ter dois ASes adicionais entrando em cena: cada FRR representando um ponto on-premises diferente, com ASN próprio.
Como uma rota "sabe" por onde já passou
Agora, o problema que o BGP resolve: como um AS sabe que existe um caminho até uma rede do outro lado do mundo, se ele nunca conversou diretamente com ela?
Pensa numa carta saindo do Brasil pro Japão, passando por Panamá, EUA, Dublin, até chegar ao destino. Cada país que recebe essa carta carimba a própria marca nela antes de repassar adiante, então quando ela chega em Dublin, dá pra ver exatamente por onde ela já passou: Brasil, Panamá, EUA. Isso é o suficiente pra qualquer país no meio do caminho saber a origem e o trajeto, sem precisar conhecer o mapa inteiro até o destino final.
Agora imagina se o correio funcionasse com a mesma lógica de decisão autônoma que o BGP tem: cada país, ao receber a carta, decidisse por conta própria se aceita repassar ou não. Nesse cenário hipotético, se a Irlanda visse o próprio carimbo já estampado numa carta que está recebendo de novo, ela saberia na hora que essa carta já passou por ali antes, em algum ciclo anterior, e recusaria, porque repassar de novo só faria essa carta girar em loop pra sempre. Esse instinto de "se eu já vi meu próprio carimbo aqui, algo está girando em círculo e eu paro isso agora" é exatamente o que o BGP tem embutido de verdade, só que automático e em milissegundos.
O nome técnico desse mecanismo é AS-path loop prevention: cada AS, ao anunciar uma rota, inclui a lista de todos os ASNs pelos quais ela já passou (o AS-path), e se um roteador BGP recebe um anúncio que já contém o próprio ASN nessa lista, ele descarta o anúncio na hora. É assim que o BGP evita loop de roteamento sem precisar de nenhuma coordenação central.
Guarda esse detalhe do AS-path, porque ele volta duas vezes: mais adiante nesse mesmo artigo, quando os dois FRR do lab anunciarem a mesma rede e a AWS precisar decidir qual caminho preferir, e de novo no Artigo 2, quando eu manipulo esse atributo de propósito com AS-path prepending.
Quais métricas a AWS realmente usa pra decidir qual rota preferir?
BGP não escolhe rota por "qual é mais rápida" ou "qual tem menos latência". Ele escolhe seguindo uma ordem de prioridade entre atributos, e três deles são os que você vai mexer de verdade trabalhando com AWS:
- AS-Path length: quanto mais curto o caminho (menos ASes no meio), mais preferido. É o critério que decide o empate no nosso lab: os dois FRR estão a um salto só da AWS, então o AS-Path de ambos tem o mesmo tamanho.
- Local Preference: define preferência de saída dentro do seu próprio AS, pra tráfego saindo em direção à AWS. Não é algo que a AWS aplica, é algo que você configura no seu lado.
- MED (Multi-Exit Discriminator): usado quando você tem mais de um caminho anunciando o mesmo prefixo pra AWS, sinalizando qual conexão é preferida pra tráfego entrando vindo da AWS. Vale um adianto importante aqui, porque ele conecta direto com a limitação da simulação que esse artigo assume: em um cenário real de Direct Connect e VPN coexistindo, a AWS prefere Direct Connect automaticamente, porque rotas de Direct Connect chegam com um MED implicitamente mais baixo que rotas de VPN. Esse comportamento não aparece de graça no nosso lab, porque as duas conexões que vamos montar são tecnicamente VPN, então não existe essa preferência automática entre elas. Manipular MED de propósito pra reproduzir esse tipo de preferência é assunto do Artigo 3.
No lab, os dois FRR vão anunciar exatamente a mesma rede, com AS-Path do mesmo tamanho. Isso significa que, quando os dois caminhos estiverem saudáveis ao mesmo tempo, a decisão de qual a AWS usa não é óbvia de antemão, e documentar o que realmente acontece no console é parte do valor desse artigo.
Toda a teoria até aqui é universal, funciona pra qualquer rede que fale BGP, dentro ou fora da nuvem. Mas na AWS, especificamente, esse protocolo aparece em três lugares**: VPN Site-to-Site, Direct Connect e Transit Gateway.** Em todos os três, o princípio é o mesmo (AS, ASN, path vector, propagação de rota), muda só o transporte por baixo. Esse artigo aprofunda o cenário de VPN porque é o mais acessível pra montar um lab com pouca infra e ver o conceito rodando de verdade, mas guarda isso: o vocabulário que você aprender aqui reaparece igualzinho no Artigo 2 (Direct Connect) e no Artigo 5 (Transit Gateway).
Quando você fala BGP com a AWS, a AWS sempre é uma das pontas da conversa, nunca um intermediário neutro carregando sua rota sem interferir. Voltando pro correio, não é como se a AWS fosse um caminhão de transporte que só carrega a carta sem abrir, ela é um país de verdade nessa analogia, com AS próprio, decidindo o que aceita receber e o que decide anunciar de volta.
O AS do lado AWS: o Virtual Private Gateway
No cenário de VPN, quem representa a AWS na conversa BGP é o VGW (Virtual Private Gateway), que tem um ASN próprio e recebe por padrão o valor 64512 caso você não escolha outro na hora de criar o VGW. Do outro lado, cada roteador on-premises é representado por um Customer Gateway, com um ASN que você escolhe.
Modo escovador de bit: o Customer Gateway, dentro da AWS, é só um objeto de configuração, um registro dizendo "esse é o IP público e o ASN desse roteador on-premises". Ele não roteia nada sozinho. O roteamento de verdade acontece no seu dispositivo físico ou virtual (cada FRR, no lab). Gente confunde os dois o tempo todo, tratando o Customer Gateway como se fosse o próprio roteador, quando na real é só a ficha cadastral dele dentro da AWS.
E aqui entra uma regra que parece detalhe burocrático mas na prática evita o primeiro erro que todo mundo comete: o ASN do VGW e o ASN de cada Customer Gateway precisam ser diferentes entre si. Se você usar o mesmo número, o BGP identifica isso como se fosse a mesma rota voltando pra ela mesma, o mecanismo de loop prevention que vimos antes entra em ação, e a rota é descartada.
Veja que, nada impede você de criar dois, três, quatro Customer Gateways diferentes, todos anexados ao mesmo VGW, cada um representando um roteador on-premises distinto, ou até uma combinação de VPN com Direct Connect, e é exatamente esse desenho que times de infra usam pra montar redundância: se um caminho cair, o outro assume.
O que a documentação da AWS deixa claro, é que esse "o outro assume" depende de BGP pra funcionar de verdade. Nas palavras da própria AWS, ao descrever esse cenário de redundância: os Customer Gateways devem anunciar a mesma rede pro VGW, e é o BGP que decide qual caminho usar e que redireciona o tráfego automaticamente se um deles falhar. Rota estática não entra nessa conversa da mesma forma, porque não existe sinalização viva dizendo "esse caminho morreu, use o outro".
De rota aprendida a rota utilizável, ou a propagação
Saber que a AWS aprendeu uma rota via BGP não é a mesma coisa que essa rota já estar disponível pra sua VPC usar. Existe uma etapa intermediária, que é onde a maioria de quem está começando trava sem entender por quê: a propagação de rota (route propagation).
Quando o VGW aprende uma rota via BGP, ela fica disponível pra ser propagada, mas só aparece de fato na route table da sua VPC se você tiver habilitado propagation naquela route table especificamente pro VGW em questão. É um interruptor separado, não é automático só porque a sessão BGP subiu.
Duas conexões, uma redundância de mentira: o problema que a rota estática não resolve
Toda vez que você sobe uma conexão VPN Site-to-Site na AWS, o console oferece duas opções sem dar muita explicação: rota estática ou BGP dinâmico. Isoladamente, cada opção parece só uma escolha de configuração. O problema aparece quando você tem duas conexões redundantes (VPN com VPN, ou VPN como backup de Direct Connect) e assume que, seja qual for a escolha, elas vão se cobrir mutuamente. Não vão, a menos que seja BGP.
Caminho fácil é com rota estática
Você digita manualmente o CIDR de destino direto na route table, apontando pra uma conexão específica, e isso sobe rápido, sem exigir nenhum conceito de protocolo, funcionando bem para o caso de uma conexão só.
O problema real aparece no cenário de duas conexões redundantes: rota estática não tem como saber, em tempo real, que uma conexão morreu e que o tráfego deveria migrar pra outra. Não existe troca de sinal vivo entre os dois lados dizendo "esse caminho não existe mais, prefira o outro". Se a topologia on-premises mudar também, alguém precisa lembrar de atualizar a rota manualmente, sem exceção.
Caminho certo (e bem mais legal) é com BGP dinâmico
Cada ponta anuncia a mesma rede via BGP, com ASN próprio, a AWS aprende os dois caminhos e escolhe entre eles usando os atributos que vimos antes (AS-Path, e os outros quando aplicável). Se uma sessão BGP cair porque o roteador daquele lado ficou indisponível, a rota correspondente é retirada automaticamente, e a AWS já está com o outro caminho aprendido e pronto pra continuar usando. Não existe intervenção manual nesse processo.
A régua de decisão
Rota estática é aceitável quando você tem uma conexão só, cenário fixo, baixa criticidade, ou quando o dispositivo on-premises simplesmente não suporta BGP. No momento em que você decide ter duas conexões pensando em redundância, rota estática deixa de fazer sentido como estratégia de alta disponibilidade, porque a redundância que ela entrega é só a de ter dois caminhos existindo, não a de ter um sistema que sabe trocar entre eles sozinho.
Tudo que foi dito até aqui é papo até você ver, com os próprios olhos, a diferença entre uma conexão estática que não migra sozinha e uma conexão BGP que migra, e é isso que o lab vai tentar mostar.
Infra alvo: 1 VPC, 2 instâncias EC2 rodando FRR (FRR-A e FRR-B, cada uma representando um ponto on-premises diferente), 1 VGW real anexado à mesma VPC, 2 Customer Gateways, 2 VPN Connections. Toda a infra de rede e computação sobe via CloudFormation, reaproveitando os mesmos dois módulos que vão aparecer de novo nos próximos artigos da série, o segundo módulo instanciado duas vezes.
Nota de honestidade sobre a simulação: idealmente, esse lab representaria Direct Connect e VPN coexistindo, que é o cenário de redundância mais comum em ambiente real. Só que Direct Connect exige circuito físico, provisionamento com parceiro e não é algo que dá pra levantar num laboratório pessoal. Por isso, as duas conexões desse lab são tecnicamente VPN Site-to-Site. FRR-A entra com o papel narrativo de "o que seria Direct Connect" e FRR-B como a VPN de fato, só pra situar o cenário que a série está construindo, mas o comportamento técnico das duas é idêntico entre si: mesmo tipo de conexão, mesmo AS-Path length, sem a preferência automática que Direct Connect real teria sobre VPN. O que esse lab prova é a mecânica de convergência do BGP quando um caminho cai, não a preferência específica de Direct Connect, que só vai aparecer de verdade quando manipularmos MED de propósito no Artigo 3.
O lab, passo a passo
Módulo 1: modules/vpc-base.yaml
Base de rede que todos os próximos artigos vão importar (via
Fn::ImportValue ou nested stack), contendo VPC, subnet pública, Internet Gateway e route table, sem alteração em relação ao módulo original.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
AWSTemplateFormatVersion: '2010-09-09'
Description: VPC base reutilizavel para a serie BGP na AWS
Parameters:
VpcCidr:
Type: String
Default: 10.0.0.0/16
PublicSubnetCidr:
Type: String
Default: 10.0.1.0/24
Resources:
VPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: !Ref VpcCidr
EnableDnsSupport: true
EnableDnsHostnames: true
Tags:
- Key: Name
Value: bgp-series-vpc
PublicSubnet:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: !Ref PublicSubnetCidr
MapPublicIpOnLaunch: true
InternetGateway:
Type: AWS::EC2::InternetGateway
AttachGateway:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
VpcId: !Ref VPC
InternetGatewayId: !Ref InternetGateway
PublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPC
PublicRoute:
Type: AWS::EC2::Route
DependsOn: AttachGateway
Properties:
RouteTableId: !Ref PublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref InternetGateway
SubnetRouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnet
RouteTableId: !Ref PublicRouteTable
Outputs:
VpcId:
Value: !Ref VPC
Export:
Name: bgp-series-vpc-id
SubnetId:
Value: !Ref PublicSubnet
Export:
Name: bgp-series-subnet-id
RouteTableId:
Value: !Ref PublicRouteTable
Export:
Name: bgp-series-routetable-idCheckpoint técnico 1: confirmar VPC e subnet criadas, route table associada, sem nenhuma rota de VPN ainda. Esse é o baseline.
Módulo 2: modules/frr-router.yaml (nested stack, instanciado duas vezes)
Mesmo módulo do desenho original, sem alteração no template, só que agora sobe duas vezes, como duas stacks separadas (
frr-a e frr-b), cada uma com um valor diferente de FrrAsn, mantendo o guardrail de acesso via SSM Session Manager, sem SSH exposto.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
AWSTemplateFormatVersion: '2010-09-09'
Description: EC2 rodando FRR, representando um ponto on-premises
Parameters:
VpcId:
Type: AWS::EC2::VPC::Id
SubnetId:
Type: AWS::EC2::Subnet::Id
FrrAsn:
Type: Number
Default: 65001
InstanceType:
Type: String
Default: t3.micro
Resources:
FrrRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: ec2.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
FrrInstanceProfile:
Type: AWS::IAM::InstanceProfile
Properties:
Roles:
- !Ref FrrRole
FrrSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Libera IPsec e BGP para a VPN AWS
VpcId: !Ref VpcId
SecurityGroupIngress:
- IpProtocol: udp
FromPort: 500
ToPort: 500
CidrIp: 0.0.0.0/0
- IpProtocol: udp
FromPort: 4500
ToPort: 4500
CidrIp: 0.0.0.0/0
- IpProtocol: tcp
FromPort: 179
ToPort: 179
CidrIp: 0.0.0.0/0
FrrInstance:
Type: AWS::EC2::Instance
Properties:
InstanceType: !Ref InstanceType
SubnetId: !Ref SubnetId
IamInstanceProfile: !Ref FrrInstanceProfile
SecurityGroupIds:
- !Ref FrrSecurityGroup
ImageId: '{{resolve:ssm:/aws/service/canonical/ubuntu/server/22.04/stable/current/amd64/hvm/ebs-gp2/ami-id}}'
UserData:
Fn::Base64: !Sub |
#!/bin/bash
apt-get update -y
apt-get install -y frr frr-pythontools strongswan
sed -i 's/bgpd=no/bgpd=yes/' /etc/frr/daemons
systemctl enable frr
systemctl restart frr
Outputs:
FrrInstanceId:
Value: !Ref FrrInstanceCheckpoint técnico 2: via Session Manager,
systemctl status frr confirmando o daemon rodando em FRR-A e em FRR-B, separadamente, antes de seguir pro próximo passo.Sequência do lab
- Deploy do
vpc-base.yaml. (Checkpoint 1, já descrito acima.) - Deploy do
frr-router.yamlcomo stack FRR-A (papel narrativo de Direct Connect),FrrAsn = 65001. (Checkpoint 2.) - Deploy do
frr-router.yamlnovamente, como stack FRR-B (VPN de fato),FrrAsn = 65002, independente da primeira. (Checkpoint 2, repetido pra FRR-B.) - Criar o VGW com ASN 64512 (default da Amazon) e anexar à VPC.
Checkpoint técnico 3: VGW em estado "attached". - Criar Customer Gateway A (IP público da FRR-A, ASN 65001) e Customer Gateway B (IP público da FRR-B, ASN 65002).
Checkpoint técnico 4: os dois Customer Gateways em estado "available".
Fase 1: rota estática
- Criar Conexão A (estática) entre Customer Gateway A e o VGW, e Conexão B (estática) entre Customer Gateway B e o mesmo VGW, ambas com a mesma rota estática de destino:
172.16.0.0/24.
Checkpoint técnico 5, documentar ao vivo: registrar exatamente o que a AWS permite aqui. Se as duas rotas estáticas pro mesmo CIDR coexistem na route table, se uma sobrescreve a outra, ou se o console impede a segunda. Esse comportamento precisa ser capturado com print real durante a execução, não adianta eu presumir aqui o que vai acontecer sem ter rodado. - Subir os túneis IPsec em FRR-A e FRR-B (sem sessão BGP nessa fase).
Checkpoint técnico 6: confirmar qual conexão está efetivamente sendo usada pela route table nesse estado "saudável" inicial. - Derrubar a conexão que estiver ativa (parar o serviço IPsec ou a instância FRR correspondente) e observar o comportamento real por alguns minutos.
Checkpoint técnico 7, o mais importante da fase estática: print da route table antes e depois da queda, mostrando se o tráfego migrou ou se ficou apontando pro caminho morto. Esse é o registro que prova (ou desmente, com rigor) a limitação descrita na teoria.
Fase 2: BGP dinâmico
- Reconfigurar Conexão A e Conexão B pra BGP dinâmico. Configurar FRR-A e FRR-B pra anunciar a mesma rede
172.16.0.0/24, cada um com seu próprio ASN.```
! FRR-A
router bgp 65001
neighbor 169.254.X.X remote-as 64512
address-family ipv4 unicast
network 172.16.0.0/24
neighbor 169.254.X.X activate! FRR-B
router bgp 65002
neighbor 169.254.Y.Y remote-as 64512
address-family ipv4 unicast
network 172.16.0.0/24
neighbor 169.254.Y.Y activate```**Checkpoint técnico 8**: as duas sessões BGP em "Established", rota propagada na route table, e registro de qual caminho a AWS escolheu usar quando os dois estão saudáveis ao mesmo tempo (empate de AS-Path, comportamento a documentar, sem a preferência de Direct Connect real que discutimos na seção de métricas).````````` - Derrubar o mesmo lado que foi derrubado na Fase 1 (mesmo teste, agora com BGP).
Checkpoint técnico 9, o contraste final: print da route table antes e depois, mostrando a convergência automática pro caminho remanescente, sem qualquer intervenção manual. Esse par de prints (Checkpoint 7 vs Checkpoint 9) é o argumento visual central do artigo inteiro.
Problemas que podem acontecer, e como resolver:
- Sessão BGP presa em "Active" e nunca chega em "Established": na maioria das vezes é porque o Security Group não está liberando UDP 500 e 4500 pro IP público da AWS, e o túnel IPsec nunca sobe de verdade, mesmo a sessão BGP tentando conectar por cima de um túnel morto.
- AWS não aceita mais de 100 (agora suporta 1000) rotas anunciadas numa mesma sessão BGP: se o FRR anunciar mais que isso, a sessão cai pra "Idle". Some redes antes de anunciar.
- eBGP multihop desabilitado por padrão na AWS: os peers BGP precisam estar diretamente conectados, um salto só. Vale pros dois FRR igualmente.
- Propagation não é automático: a sessão BGP pode estar saudável, rota sendo anunciada e recebida, e mesmo assim não aparecer na route table, porque o toggle de propagation daquela route table específica nunca foi habilitado.
- Duas rotas estáticas pro mesmo CIDR: esse é o gotcha central da Fase 1, e precisa ser documentado com o comportamento real observado no console, não presumido. Se a AWS aceitar as duas e usar sempre a primeira cadastrada, ou se rejeitar a segunda, ou qualquer outro comportamento, é isso que vira o parágrafo mais valioso dessa seção.
- Não confundir a simulação com Direct Connect real: como as duas conexões do lab são tecnicamente VPN, não espere ver a AWS preferindo uma sobre a outra automaticamente. Essa preferência é real no mundo Direct Connect vs VPN, mas exige circuito físico pra existir, e manipulação deliberada de MED pra ser reproduzida em laboratório, o que fica pro Artigo 3.
Quando eu NÃO uso BGP dinâmico?
Vale documentar honestamente, porque nem toda infra precisa disso:
- VPN temporária ou de PoC, que vai ser desmontada em dias.
- Ambiente de baixíssima criticidade, com uma conexão só, onde ninguém vai mexer na topologia depois de configurado.
- Quando o dispositivo on-premises simplesmente não fala BGP (alguns firewalls legados e appliances mais baratos só fazem rota estática, sem opção).
Nesse último caso, vale ser honesto com quem está lendo: se o seu dispositivo não suporta BGP e você tem duas conexões redundantes mesmo assim, aceite que a redundância real vai depender de intervenção manual em caso de falha, e documente isso como risco conhecido, em vez de vender internamente uma resiliência que a arquitetura não entrega (ou faça um script cabuloso para fazer isso automático) (ou melhor ainda grite para seu gestor que isso não se faz).
Conclusão
BGP não é feature de VPN, é a camada que decide se a redundância que você desenhou no papel existe de verdade na hora que ela precisa existir. Duas conexões em rota estática são dois caminhos que existem, não um sistema que sabe trocar entre eles.
Esse artigo provou isso com a infra mais simples possível, duas VPNs fazendo o papel de um cenário maior, e um teste que qualquer um pode reproduzir. No próximo artigo, o mesmo protocolo entra numa Direct Connect de verdade, e a gente passa a manipular de propósito qual caminho a AWS prefere, com AS-path prepending, em vez de só deixar o BGP convergir sozinho.
Series: AWS Network (3 articles)
- 2AWS Network: Onde ter duas VPNs, dois DX ou conexões hibridas pode falhar. This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article