Pular para o conteúdo principal

Laboratório Técnico: Design and Implement Azure Route Server

Questões

Questão 1 — Múltipla Escolha

Uma equipe de rede precisa integrar um Network Virtual Appliance (NVA) com roteamento dinâmico BGP à infraestrutura do Azure, sem configurar rotas estáticas manualmente em cada Virtual Network. O objetivo é que as rotas aprendidas pelo NVA sejam propagadas automaticamente para as VNets conectadas.

Qual é o papel do Azure Route Server nesse cenário?

A) Substitui o NVA como ponto central de roteamento, eliminando a necessidade de BGP no ambiente.

B) Atua como plano de controle BGP, trocando rotas com o NVA e propagando-as automaticamente para as VNets via infraestrutura da plataforma Azure.

C) Funciona como um gateway de roteamento que encaminha pacotes de dados entre o NVA e as VNets, assumindo o plano de dados.

D) Sincroniza tabelas de rotas entre VNets diferentes por meio de peering de rede virtual, sem envolver BGP.


Questão 2 — Cenário Técnico

Um arquiteto implantou o Azure Route Server em uma VNet que já contém um ExpressRoute Gateway. Após a configuração, ele percebe que rotas aprendidas via ExpressRoute estão sendo anunciadas para o NVA conectado ao Route Server, e rotas do NVA estão sendo propagadas para a rede on-premises via ExpressRoute.

Esse comportamento era inesperado. Qual configuração foi responsável por isso?

A) A propriedade allowBranchToBranchTraffic foi habilitada automaticamente pelo Route Server ao detectar o gateway ExpressRoute na mesma VNet.

B) O Route Server foi implantado na mesma sub-rede do ExpressRoute Gateway, causando conflito de tabela de rotas.

C) A funcionalidade Branch-to-Branch foi habilitada no Route Server, permitindo que ele troque rotas entre o NVA e o gateway ExpressRoute.

D) O peering BGP entre o NVA e o Route Server foi configurado com o ASN padrão do ExpressRoute, gerando troca indevida de rotas.


Questão 3 — Verdadeiro ou Falso

O Azure Route Server participa do plano de dados da rede, ou seja, os pacotes de tráfego entre o NVA e as VNets passam por ele antes de chegarem ao destino final.


Questão 4 — Cenário Técnico

Um engenheiro está configurando o peering BGP entre um NVA e o Azure Route Server. Após concluir a configuração no portal, o peering permanece no estado Connecting indefinidamente.

Observe o trecho de configuração do NVA:

neighbor 10.1.1.4 remote-as 65515
neighbor 10.1.1.4 ebgp-multihop 2
neighbor 10.1.1.4 update-source loopback0

Qual é a causa mais provável do problema?

A) O ASN configurado no NVA deve ser idêntico ao ASN do Route Server (65515), pois o peering é do tipo iBGP.

B) O Route Server exige que o peering BGP use o endereço IP da interface diretamente conectada como update-source, e não uma interface de loopback.

C) O parâmetro ebgp-multihop está configurado com valor 2, mas o Route Server exige valor mínimo de 5 para aceitar sessões BGP externas.

D) O Route Server não aceita sessões BGP iniciadas pelo NVA; a sessão deve sempre ser iniciada pelo próprio Route Server.


Questão 5 — Múltipla Escolha

Uma empresa possui duas VNets conectadas via VNet Peering. O Azure Route Server está implantado na VNet A. A equipe deseja que o NVA na VNet A também influencie o roteamento da VNet B.

Qual configuração é obrigatória para que as rotas aprendidas pelo Route Server sejam propagadas para a VNet B?

A) Implantar um segundo Route Server na VNet B e configurar peering BGP entre os dois Route Servers.

B) Habilitar a opção Use Remote Gateway no peering da VNet B em direção à VNet A, onde o Route Server está implantado.

C) Habilitar a opção Use Remote Gateway or Route Server no peering da VNet B em direção à VNet A.

D) Configurar uma User Defined Route (UDR) na VNet B apontando para o IP do Route Server como next hop.


Gabarito e Explicações

Gabarito — Questão 1

Resposta: B

O Azure Route Server atua exclusivamente no plano de controle, trocando rotas via BGP com o NVA e injetando essas rotas na infraestrutura de roteamento das VNets automaticamente, sem intervenção manual. Ele não substitui o NVA nem assume funções de encaminhamento de pacotes.

A alternativa C representa o equívoco mais comum: confundir plano de controle com plano de dados. O Route Server nunca toca o tráfego de produção. A alternativa A nega a necessidade do BGP, que é exatamente o protocolo central da solução. A alternativa D descreve VNet Peering comum, sem relação com Route Server.


Gabarito — Questão 2

Resposta: C

O comportamento descrito é exatamente o efeito da funcionalidade Branch-to-Branch (allowBranchToBranchTraffic). Quando habilitada, o Route Server passa a trocar rotas entre todos os peers BGP conectados a ele, o que inclui gateways ExpressRoute e VPN na mesma VNet. Isso permite que rotas aprendidas via ExpressRoute cheguem ao NVA, e vice-versa.

Esse recurso é desabilitado por padrão justamente para evitar propagação não intencional entre branches. A alternativa A descreve uma ativação automática que não existe. A alternativa B é incorreta porque o Route Server possui sua própria sub-rede dedicada (RouteServerSubnet) e não compartilha sub-rede com gateways. A alternativa D confunde ASN com o mecanismo de propagação.


Gabarito — Questão 3

Resposta: Falso

O Azure Route Server opera exclusivamente no plano de controle. Ele troca informações de roteamento via BGP com os NVAs, mas nenhum pacote de dados atravessa o Route Server. O tráfego de produção continua fluindo diretamente entre as VMs, NVAs e gateways, conforme as rotas programadas na infraestrutura do Azure.

Esse é um dos conceitos mais críticos do Route Server e fonte frequente de confusão. Compreender essa distinção evita erros de dimensionamento e de expectativa sobre o comportamento do tráfego em cenários de alta disponibilidade.


Gabarito — Questão 4

Resposta: B

O Azure Route Server requer que a sessão BGP seja estabelecida usando o endereço IP da interface diretamente conectada ao Route Server, e não uma interface de loopback. O uso de update-source loopback0 faz com que os pacotes BGP partam de um endereço que o Route Server não reconhece como origem válida do peer, impedindo o estabelecimento da sessão.

A alternativa A está errada porque o peering entre NVA e Route Server é eBGP: o ASN do NVA deve ser diferente do ASN do Route Server (65515). A alternativa C é incorreta porque o valor padrão e aceito para ebgp-multihop no contexto do Route Server é 1 (conectividade direta na mesma VNet). A alternativa D está errada porque tanto o NVA quanto o Route Server podem iniciar a sessão BGP.


Gabarito — Questão 5

Resposta: C

Para que o Azure Route Server propague rotas para uma VNet conectada via peering, é obrigatório habilitar a opção "Use Remote Gateway or Route Server" no lado da VNet remota (VNet B). Essa opção instrui o Azure a aceitar e programar rotas provenientes do Route Server implantado na VNet par (VNet A).

A alternativa B descreve a opção correta para o cenário clássico de gateway VPN/ExpressRoute, mas a partir de uma atualização do portal e da API, o nome correto que abrange Route Server é "Use Remote Gateway or Route Server". Usar apenas "Use Remote Gateway" pode não ativar o comportamento esperado em implantações modernas. A alternativa A está errada porque não existe peering BGP entre Route Servers. A alternativa D está errada porque UDRs controlam o plano de dados, não a propagação de rotas aprendidas via BGP pelo Route Server.