Laboratório Técnico: Recommend a route advertisement configuration
Questões
Questão 1 — Múltipla Escolha
Uma empresa possui dois ambientes conectados ao Azure via ExpressRoute: a sede principal, com um circuito de 1 Gbps, e uma filial, com um circuito de 200 Mbps. Ambos os circuitos estão associados ao mesmo ExpressRoute Gateway em uma Virtual Network (VNet). O time de rede precisa garantir que o tráfego de saída do Azure com destino à sede utilize preferencialmente o circuito da sede, e não o da filial.
Qual mecanismo de roteamento deve ser configurado para influenciar essa preferência no lado do Azure?
A) Aumentar o peso da rota (route weight) no circuito da filial para torná-lo menos preferido pelo gateway
B) Configurar AS Path Prepending nas rotas anunciadas pela sede para que o Azure prefira o caminho mais curto
C) Aumentar o peso da rota (route weight) no circuito da sede para que o gateway do Azure prefira esse caminho
D) Configurar Local Preference no BGP do gateway do Azure para priorizar o circuito da sede
Questão 2 — Cenário Técnico
Um engenheiro configura uma conexão Site-to-Site VPN entre o Azure e um datacenter on-premises. O dispositivo VPN on-premises anuncia via BGP o prefixo 10.10.0.0/16. A VNet do Azure possui o espaço de endereços 10.20.0.0/16.
Após a conexão ser estabelecida, máquinas virtuais na VNet conseguem pingar o gateway on-premises, mas não conseguem alcançar hosts em sub-redes específicas dentro do bloco 10.10.0.0/16. O engenheiro verifica que a tabela de rotas efetivas das VMs mostra apenas a rota para 10.10.0.0/16.
Qual é a causa mais provável do problema?
A) O Local Network Gateway está configurado com um espaço de endereços diferente do prefixo anunciado via BGP
B) O dispositivo VPN on-premises não está anunciando os prefixos mais específicos das sub-redes via BGP, apenas o supernet
C) A VNet do Azure não suporta roteamento para prefixos menores que /16 via BGP
D) O VPN Gateway do Azure está descartando prefixos mais específicos por conflito com o espaço de endereços da VNet
Questão 3 — Verdadeiro ou Falso
Ao utilizar o Azure Route Server em conjunto com uma Network Virtual Appliance (NVA), as rotas aprendidas pela NVA via BGP e propagadas ao Route Server são automaticamente injetadas nas tabelas de rotas de todas as VNets emparelhadas (peered) com a VNet que contém o Route Server, desde que o Branch-to-Branch esteja desabilitado.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma organização utiliza o Azure Virtual WAN (vWAN) com hubs gerenciados e possui filiais conectadas via VPN S2S e uma VNet spoke conectada ao hub. O time de rede reporta que as filiais conseguem se comunicar com a VNet spoke, mas duas filiais não conseguem se comunicar diretamente entre si.
A configuração atual do hub é:
Hub Routing Preference: ExpressRoute
Branch-to-Branch: Disabled
Qual alteração resolve o problema de comunicação entre as filiais?
A) Alterar o Hub Routing Preference de ExpressRoute para VPN
B) Habilitar o Branch-to-Branch nas configurações do hub vWAN
C) Criar uma User Defined Route (UDR) na VNet spoke apontando para o hub
D) Configurar BGP peering diretamente entre os dispositivos VPN das filiais
Questão 5 — Múltipla Escolha
Um arquiteto está projetando a conectividade entre duas regiões do Azure usando VNet Peering Global. A solução deve permitir que recursos em ambas as VNets se comuniquem com a rede on-premises conectada via ExpressRoute a apenas uma das VNets.
Qual configuração de gateway transit é necessária para que a VNet remota (sem ExpressRoute) alcance a rede on-premises?
A) Habilitar Allow Gateway Transit na VNet que possui o gateway ExpressRoute e Use Remote Gateways na VNet remota
B) Habilitar Use Remote Gateways em ambas as VNets para que o peering seja bidirecional
C) Habilitar Allow Gateway Transit em ambas as VNets, pois o peering global exige configuração simétrica
D) Habilitar Allow Forwarded Traffic na VNet que possui o gateway e Use Remote Gateways na VNet remota
Gabarito e Explicações
Gabarito — Questão 1
Resposta: C
O route weight é um atributo local do gateway do Azure usado para desempatar rotas aprendidas via BGP quando múltiplos caminhos estão disponíveis. Um peso maior indica preferência. Como ambos os circuitos chegam ao mesmo gateway, aumentar o peso no circuito da sede faz com que o Azure prefira aquele caminho ao tomar decisões de roteamento de saída.
O erro principal dos distratores está na confusão de escopo: AS Path Prepending (B) é uma técnica para influenciar o roteamento de entrada no Azure, tornando um caminho menos preferido para tráfego vindo de fora, não de saída. Local Preference (D) é um atributo BGP que existe dentro de um AS e não é configurável diretamente no gateway do Azure. Aumentar o peso da filial (A) tornaria aquele caminho mais preferido, o oposto do objetivo.
Gabarito — Questão 2
Resposta: B
Quando o BGP está habilitado em uma conexão VPN, o Local Network Gateway perde a função de definir os prefixos alcançáveis manualmente. A tabela de rotas do Azure é populada exclusivamente pelos prefixos anunciados via BGP pelo peer on-premises. Se o dispositivo on-premises anuncia apenas o supernet 10.10.0.0/16 e não os prefixos mais específicos das sub-redes, o Azure aprende apenas essa rota agregada. O tráfego chega ao gateway on-premises, mas sem informação de sub-rede mais específica, o roteamento local pode falhar para hosts específicos dependendo da topologia on-premises.
A alternativa (A) seria relevante apenas em conexões sem BGP. A alternativa (C) é incorreta: o Azure suporta prefixos até /32 via BGP. A alternativa (D) é incorreta pois 10.10.0.0/16 e 10.20.0.0/16 não se sobrepõem, não havendo conflito.
Gabarito — Questão 3
Falso
O Azure Route Server propaga rotas aprendidas da NVA para os gateways (VPN e ExpressRoute) e para as VNets na mesma VNet. Para que essas rotas se propaguem para VNets emparelhadas, o peering deve ter o gateway transit configurado adequadamente, e isso não é automático apenas por existir o peering.
Além disso, a condição da afirmação inverte a lógica do Branch-to-Branch: esse recurso, quando habilitado, permite que o Route Server troque rotas entre os gateways e a NVA, possibilitando comunicação entre branches. Desabilitá-lo restringe esse comportamento. A afirmação combina dois conceitos corretos isoladamente de forma incorreta, criando uma conclusão falsa.
Gabarito — Questão 4
Resposta: B
No Azure Virtual WAN, a comunicação direta entre branches (filial para filial) é controlada pela configuração Branch-to-Branch. Quando essa opção está desabilitada, o hub não propaga rotas de uma filial para outra, mesmo que ambas estejam conectadas ao mesmo hub. Habilitar essa configuração resolve o problema sem necessidade de alterações nas VNets spoke ou nos dispositivos das filiais.
A alternativa (A) altera a preferência de roteamento do hub, mas não habilita a troca de rotas entre branches. A alternativa (C) afeta o tráfego da VNet spoke, não a comunicação entre filiais. A alternativa (D) criaria um túnel direto fora do vWAN, o que contorna a solução gerenciada e não é a abordagem correta dentro do modelo vWAN.
Gabarito — Questão 5
Resposta: A
O gateway transit no VNet Peering funciona de forma assimétrica por design. A VNet que possui o gateway deve ter Allow Gateway Transit habilitado, autorizando que outras VNets usem seu gateway. A VNet remota, que não possui gateway, deve ter Use Remote Gateways habilitado para apontar para o gateway da VNet parceira.
A alternativa (B) é incorreta porque Use Remote Gateways só pode ser habilitado em VNets que não possuem um gateway próprio. Configurar isso em ambas resultaria em erro. A alternativa (C) é incorreta: a configuração não é simétrica e Allow Gateway Transit em ambas não faz sentido lógico. A alternativa (D) confunde Allow Forwarded Traffic (que permite tráfego originado fora da VNet passar pelo peering) com Allow Gateway Transit (que permite uso do gateway), sendo conceitos distintos com finalidades diferentes.