2.5 Azure Route Server & Dynamic NVA Route Exchange
Key Takeaways
- Azure Route Server acts as a managed BGP route reflector inside a VNet: it exchanges routes between BGP-capable NVAs and the Azure SDN, and it never carries data traffic between the NVA and the VMs.
- Route Server requires a dedicated subnet named RouteServerSubnet of /27 or larger, uses ASN 65515, supports only 16-bit (2-byte) ASNs on the peer side, and requires the NVA to support multi-hop external BGP.
- Per-deployment limits are 16 BGP peers, 4,000 routes accepted from each BGP peer, 10,000 total prefixes, 500 virtual networks, and 50,000 VMs including peered VNets.
- Route exchange between an NVA and a VPN or ExpressRoute gateway does not happen by default; you must enable the branch-to-branch setting, and it provides transit only for site-to-site VPN, never for point-to-site.
- Neither a user-defined route nor a network security group can be associated with RouteServerSubnet, and Route Server cannot force inter-subnet traffic inside one VNet through an NVA because system routes still win over BGP routes.
Azure Route Server & Dynamic NVA Route Exchange
When you insert a third-party network virtual appliance — an SD-WAN concentrator, a next-generation firewall, a router NVA — into an Azure VNet, something has to tell the Azure software-defined network which prefixes now sit behind that appliance. Without help, the answer is user-defined routes maintained by hand: every new on-premises prefix, every SD-WAN topology change, and every failover means editing route tables across dozens of subnets.
Azure Route Server removes that toil. It is a fully managed service that speaks BGP with your NVAs and programs the routes it learns straight into the Azure SDN, so every VM in the virtual network — and in peered virtual networks that use the remote gateway or Route Server — picks them up automatically.
[!IMPORTANT] Route Server exchanges routes, not packets. It is a control-plane service. Data traffic goes directly from the VM to the NVA and from the NVA to its destination. Any exam option that describes Route Server as forwarding, inspecting, or hairpinning traffic is wrong.
1. Deployment Requirements
| Requirement | Value |
|---|---|
| Dedicated subnet name | RouteServerSubnet — the name is mandatory |
| Minimum subnet size | /27 or larger |
| Instances per VNet | Exactly one Route Server per virtual network |
| Route Server ASN | 65515 (fixed) |
| Routing protocol | BGP only; the NVA must support multi-hop eBGP because Route Server lives in its own subnet |
| Peer ASN | Must differ from 65515; 16-bit (2-byte) ASNs only — 32-bit/4-byte ASNs are not supported |
| Public IP | Required, used by the Azure control plane to manage the service |
| IPv6 | Not supported |
| Redundancy | Two instances; peer each NVA with both instances and advertise the same routes to both |
ASNs you cannot use on the NVA
Azure reserves the public ASNs 8074, 8075, and 12076 and the private ASNs 65515, 65517, 65518, 65519, and 65520. IANA reserves 23456, 64496-64511, and 65535-65551. Configuring any of these on the NVA breaks peering.
[!CAUTION] AS_PATH loop prevention. If an NVA advertises a route whose
AS_PATHalready contains 65515 — for example65001 65515— Route Server sees its own ASN in the path and drops the route as a BGP loop. The prefix is neither installed nor propagated. This is standard BGP behaviour, but in Azure it surfaces as "one specific prefix silently never appears in effective routes."
2. Service Limits
| Resource | Limit per deployment |
|---|---|
| Number of BGP peers | 16 |
| Routes each BGP peer can advertise to Route Server | 4,000 |
| VMs in the VNet, including peered VNets | 50,000 |
| Virtual networks supported | 500 |
| Total on-premises + Azure VNet prefixes | 10,000 |
Exceeding 4,000 routes from a single peer tears down the BGP session rather than dropping the excess. Worse, the count is evaluated as current routes plus routes in the incoming update: an NVA that has already advertised 2,001 routes and then re-advertises the same 2,001 routes is counted as 4,002, and the session drops. Design NVA advertisements with summarisation, not with the raw prefix list.
When branch-to-branch is enabled, the total routes advertised from the VNet address space and Route Server toward an ExpressRoute circuit must not exceed 1,000 — the ExpressRoute route-advertisement limit.
Capacity and routing infrastructure units
By default a Route Server deploys with two routing infrastructure units, supporting 4,000 connected VMs across its VNet and peered VNets. You add units in increments of 1,000 VMs up to the 50,000 ceiling.
3. Branch-to-Branch: The Setting Everyone Forgets
By default, Route Server does not propagate routes between an NVA and a virtual network gateway. Routes learned from the SD-WAN NVA are not handed to the ExpressRoute or VPN gateway, and gateway routes are not handed to the NVA. Enabling branch-to-branch turns that exchange on.
| Scenario | Works without branch-to-branch? |
|---|---|
| NVA routes reach VMs in the VNet and peered VNets | Yes |
| NVA routes reach ExpressRoute-connected on-premises | No — requires branch-to-branch |
| ExpressRoute routes reach the NVA | No — requires branch-to-branch |
| Transit between ExpressRoute and a site-to-site VPN connection | Requires branch-to-branch |
| Transit between ExpressRoute and a point-to-site VPN connection | Not supported at all |
Route preference
When the same prefix is learned over ExpressRoute, VPN, and SD-WAN, ExpressRoute is preferred by default. You can change this with the Route Server routing preference setting.
VPN gateway prerequisites
For an Azure VPN gateway to work with Route Server it must be configured in active-active mode with ASN 65515. BGP does not have to be enabled on the VPN gateway for it to communicate with Route Server.
4. Multiple NVAs, ECMP, and Route Control
If two NVAs advertise the same prefix with the same AS path length, Route Server programs multiple copies of the route with different next hops and the host performs Equal-Cost Multi-Path (ECMP) load distribution — an active/active design. If one NVA advertises a shorter AS path, only that NVA's route is programmed — an active/passive design driven by AS-path prepending on the standby appliance.
Route Server preserves both the AS path and the BGP communities of routes it receives. Two mechanisms let you shape advertisements:
NO_ADVERTISEcommunity — an NVA tagging a route withNO_ADVERTISEstops Route Server from passing it to any other peer, including the ExpressRoute gateway. This is the simplest way to stay under the 1,000-route ExpressRoute limit.- Route maps — filter routes, aggregate prefixes, and modify BGP attributes such as
AS-PATHandCommunityon BGP peerings, ExpressRoute gateway connections, and VPN gateway connections.
BGP timers
Route Server uses a keepalive of 60 seconds and a hold timer of 180 seconds — the same values as Azure virtual network gateways.
5. What Route Server Cannot Do
These negative constraints are where the exam lives.
| Constraint | Consequence |
|---|---|
No UDR on RouteServerSubnet | You cannot steer or blackhole traffic in that subnet |
No NSG on RouteServerSubnet | The subnet cannot be filtered |
| Cannot force inter-subnet traffic through an NVA inside one VNet | System routes for VNet, peering, and service endpoint traffic beat BGP routes even when the BGP route is more specific. Use UDRs, or an internal Load Balancer in HA ports mode, for intra-VNet service chaining |
| Cannot be deployed in a spoke connected to a Virtual WAN hub | Virtual WAN hubs have their own routing engine |
| Two Route Servers do not chain | NVA routes learned by one Route Server are dropped by a second Route Server reached over an ExpressRoute MSEE. Build a direct tunnel between the NVAs instead |
| No IPv6 | Deploying Route Server into a VNet with an IPv6 address space breaks IPv6 connectivity |
[!WARNING] Deployment causes downtime. Creating or deleting a Route Server in a VNet that already contains an ExpressRoute or VPN gateway causes about 10 minutes of downtime, and the deployment itself can take 30-60 minutes. Microsoft recommends a 60-minute maintenance window. Creating a VNet peering while Route Server is running also triggers a BGP soft reset — and a hard reset if the NVA does not support BGP route refresh, which briefly disrupts traffic traversing the NVAs.
A retail enterprise deploys an SD-WAN NVA pair into a hub VNet alongside an existing ExpressRoute gateway, and adds an Azure Route Server. BGP sessions between both NVAs and both Route Server instances come up, and spoke VMs immediately learn the branch prefixes advertised by the SD-WAN appliances. However, the ExpressRoute-connected datacenter cannot reach any SD-WAN branch. What must be changed?
A firewall NVA peered with Azure Route Server has been advertising 2,001 routes successfully for several weeks. During a routine configuration reload the appliance re-advertises the same 2,001 prefixes in a single BGP update, and the peering with Route Server drops. Which documented behaviour explains this?
An architect wants all traffic between the web subnet and the database subnet inside a single virtual network to be inspected by a firewall NVA. They propose advertising more specific prefixes for each subnet from the NVA to Azure Route Server so that BGP routes override the default behaviour. Why will this design fail?