Technical Lab: Design and Implement Azure Route Server
Questions
Question 1 — Multiple Choice
A network team needs to integrate a Network Virtual Appliance (NVA) with BGP dynamic routing into the Azure infrastructure, without manually configuring static routes in each Virtual Network. The goal is for routes learned by the NVA to be automatically propagated to connected VNets.
What is the role of Azure Route Server in this scenario?
A) Replaces the NVA as the central routing point, eliminating the need for BGP in the environment.
B) Acts as a BGP control plane, exchanging routes with the NVA and automatically propagating them to VNets via Azure platform infrastructure.
C) Functions as a routing gateway that forwards data packets between the NVA and VNets, assuming the data plane.
D) Synchronizes route tables between different VNets through virtual network peering, without involving BGP.
Question 2 — Technical Scenario
An architect deployed Azure Route Server in a VNet that already contains an ExpressRoute Gateway. After configuration, he notices that routes learned via ExpressRoute are being advertised to the NVA connected to the Route Server, and routes from the NVA are being propagated to the on-premises network via ExpressRoute.
This behavior was unexpected. Which configuration was responsible for this?
A) The allowBranchToBranchTraffic property was automatically enabled by the Route Server upon detecting the ExpressRoute gateway in the same VNet.
B) The Route Server was deployed in the same subnet as the ExpressRoute Gateway, causing route table conflicts.
C) The Branch-to-Branch functionality was enabled on the Route Server, allowing it to exchange routes between the NVA and ExpressRoute gateway.
D) BGP peering between the NVA and Route Server was configured with the ExpressRoute default ASN, generating improper route exchange.
Question 3 — True or False
Azure Route Server participates in the network data plane, meaning traffic packets between the NVA and VNets pass through it before reaching their final destination.
Question 4 — Technical Scenario
An engineer is configuring BGP peering between an NVA and Azure Route Server. After completing the configuration in the portal, the peering remains in Connecting state indefinitely.
Observe the NVA configuration snippet:
neighbor 10.1.1.4 remote-as 65515
neighbor 10.1.1.4 ebgp-multihop 2
neighbor 10.1.1.4 update-source loopback0
What is the most likely cause of the problem?
A) The ASN configured on the NVA must be identical to the Route Server ASN (65515), as the peering is iBGP type.
B) Route Server requires BGP peering to use the directly connected interface IP address as update-source, not a loopback interface.
C) The ebgp-multihop parameter is configured with value 2, but Route Server requires a minimum value of 5 to accept external BGP sessions.
D) Route Server does not accept BGP sessions initiated by the NVA; the session must always be initiated by Route Server itself.
Question 5 — Multiple Choice
A company has two VNets connected via VNet Peering. Azure Route Server is deployed in VNet A. The team wants the NVA in VNet A to also influence routing in VNet B.
Which configuration is mandatory for routes learned by the Route Server to be propagated to VNet B?
A) Deploy a second Route Server in VNet B and configure BGP peering between the two Route Servers.
B) Enable the Use Remote Gateway option in VNet B's peering toward VNet A, where the Route Server is deployed.
C) Enable the Use Remote Gateway or Route Server option in VNet B's peering toward VNet A.
D) Configure a User Defined Route (UDR) in VNet B pointing to the Route Server IP as next hop.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Azure Route Server operates exclusively in the control plane, exchanging routes via BGP with the NVA and injecting these routes into VNet routing infrastructure automatically, without manual intervention. It does not replace the NVA nor assume packet forwarding functions.
Alternative C represents the most common misconception: confusing control plane with data plane. Route Server never touches production traffic. Alternative A denies the need for BGP, which is precisely the core protocol of the solution. Alternative D describes common VNet Peering, unrelated to Route Server.
Answer Key — Question 2
Answer: C
The described behavior is exactly the effect of the Branch-to-Branch functionality (allowBranchToBranchTraffic). When enabled, Route Server starts exchanging routes between all BGP peers connected to it, which includes ExpressRoute and VPN gateways in the same VNet. This allows routes learned via ExpressRoute to reach the NVA, and vice versa.
This feature is disabled by default precisely to avoid unintentional propagation between branches. Alternative A describes an automatic activation that doesn't exist. Alternative B is incorrect because Route Server has its own dedicated subnet (RouteServerSubnet) and doesn't share subnets with gateways. Alternative D confuses ASN with the propagation mechanism.
Answer Key — Question 3
Answer: False
Azure Route Server operates exclusively in the control plane. It exchanges routing information via BGP with NVAs, but no data packets traverse the Route Server. Production traffic continues to flow directly between VMs, NVAs, and gateways, according to routes programmed in Azure infrastructure.
This is one of the most critical concepts of Route Server and a frequent source of confusion. Understanding this distinction prevents sizing errors and behavioral expectations in high availability scenarios.
Answer Key — Question 4
Answer: B
Azure Route Server requires that the BGP session be established using the IP address of the interface directly connected to Route Server, not a loopback interface. Using update-source loopback0 causes BGP packets to originate from an address that Route Server doesn't recognize as a valid peer source, preventing session establishment.
Alternative A is wrong because peering between NVA and Route Server is eBGP: the NVA ASN must be different from the Route Server ASN (65515). Alternative C is incorrect because the default and accepted value for ebgp-multihop in Route Server context is 1 (direct connectivity in the same VNet). Alternative D is wrong because both NVA and Route Server can initiate the BGP session.
Answer Key — Question 5
Answer: C
For Azure Route Server to propagate routes to a VNet connected via peering, it's mandatory to enable the "Use Remote Gateway or Route Server" option on the remote VNet side (VNet B). This option instructs Azure to accept and program routes originating from the Route Server deployed in the peer VNet (VNet A).
Alternative B describes the correct option for the classic VPN/ExpressRoute gateway scenario, but from a portal and API update, the correct name that encompasses Route Server is "Use Remote Gateway or Route Server". Using only "Use Remote Gateway" may not activate the expected behavior in modern deployments. Alternative A is wrong because BGP peering between Route Servers doesn't exist. Alternative D is wrong because UDRs control the data plane, not the propagation of routes learned via BGP by Route Server.