Static routes with UDRs are great—until networks grow, routes change, and you’re updating dozens of route tables by hand at 1am on a Sunday. Enter BGP (Border Gateway Protocol), the internet’s gift to dynamic routing and Azure Route Server, which lets your NVAs speak BGP with the fabric itself.

In this post, we explore how to use Azure Route Server with NVAs to enable dynamic routing, reduce static configuration overhead, and build smarter, faster convergence into your Azure network designs.

What is Azure Route Server?

Azure Route Server is a managed service that simplifies routing between your network virtual appliances (NVAs) and Azure’s virtual network routing, using Border Gateway Protocol (BGP). It acts as a bridge between your BGP-capable NVA and Azure’s control plane.

In plain terms: it lets your NVA advertise and learn routes dynamically, without needing API access or route table edits.

Key capabilities

• BGP peering between Azure and your NVA
• Dynamic route updates from NVA → VNet and vice versa
• No need for manual UDR updates for many routing changes
• Supports active/active and active/passive appliance setups

How It Works

Basic flow:

1. Deploy Azure Route Server into a dedicated /27 subnet (RouteServerSubnet) in your VNet
2. Deploy your NVA in the same or peered VNet with BGP enabled
3. Configure BGP peering between Azure Route Server and your NVA (ASNs, IPs)
4. Routes learned by your NVA are injected into Azure’s routing fabric
5. Azure can also advertise “default routes” and VNet address space back to the NVA

Real-world impact

Let’s say you’re using a third-party firewall or SD-WAN appliance to control all outbound traffic.

With Azure Route Server:

• The NVA advertises a 0.0.0.0/0 default route to Azure via BGP
• Azure updates the route tables dynamically, no UDR required
• As workloads scale, new subnets automatically follow the NVA without needing manual updates

Deploy another appliance? Adjust policy? As long as your BGP config is updated on the appliance, Azure routes follow.

Architecture Diagram

Azure Implementation

Azure Portal Steps

1. Deploy virtual network with /27 subnet named RouteServerSubnet
2. Deploy Azure Route Server into that subnet
3. Deploy NVA (with BGP enabled) into same VNet or peered VNet
4. Use CLI or Portal to configure BGP peering:
   • ASN for your NVA
   • NVA BGP peer IP
   • Enable peerASN, peerIP, bgpPeeringEnabled
5. Verify routing table on VM shows NVA via dynamic route

Bicep Deployment Example

 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

param vnetName string = 'hub-vnet'

resource vnet 'Microsoft.Network/virtualNetworks@2023-02-01' existing = {
  name: vnetName
}

resource rsSubnet 'Microsoft.Network/virtualNetworks/subnets@2023-02-01' = {
  name: 'RouteServerSubnet'
  parent: vnet
  properties: {
    addressPrefix: '10.0.1.0/26'
  }
}

resource publicIp 'Microsoft.Network/publicIPAddresses@2020-05-01' = {
  name: 'myRouteServer-pip'
  location: resourceGroup().location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIPAllocationMethod: 'Static'
    publicIPAddressVersion: 'IPv4'
    idleTimeoutInMinutes: 4
  }
}

resource RouteServer 'Microsoft.Network/virtualHubs@2020-06-01' = {
  name: 'myRouteServer'
  location: resourceGroup().location
  properties: {
    sku: 'Standard'
  }
}

resource ipconfig  'Microsoft.Network/virtualHubs/ipConfigurations@2020-06-01' = {
  name: 'myRouteServer-ipconfig'
  parent: RouteServer
  properties: {
    subnet:{
      id: rsSubnet.id
    }
    publicIPAddress: {
      id: publicIp.id
    }
  }
}

Note: Azure Route Server uses ASN 65515. Your NVA must use a different ASN.

Gotchas & Edge Cases

• NVA must support BGP: Not all appliances support this out of the box—check feature sets
• No UDRs with same prefixes: They’ll override BGP-learned routes. Remove conflicting UDRs where Route Server is in use
• NVA failover needs BFD or control plane detection: Otherwise route withdrawal is slow
• Works best within one region/VNet. Peering adds complexity to route propagation

Best Practices

• Use /27 subnet for RouteServerSubnet (mandatory requirement)
• Always validate route propagation using Get-AzEffectiveRouteTable or Network Watcher
• Avoid static UDRs on subnets meant to follow BGP-learned routes
• Monitor with Network Insights and logs from Route Server + NVA
• Design for active/passive failover with route priorities or BGP communities

Learn More

• Azure Route Server overview
• Tutorial: Configure BGP peering between Azure Route Server and network virtual appliance (NVA)
• Effective routes troubleshooting