Azure Route Server

Azure Route Server is a fully managed, regional service that simplifies dynamic routing between your network virtual appliances (NVAs) and your virtual networks (VNets) using the Border Gateway Protocol (BGP). Before Route Server, to enable an NVA (like a firewall or SD-WAN appliance) to exchange routes with Azure’s infrastructure, you had to either:

Route Server eliminates these pain points by acting as a BGP route reflector. It peers with your NVAs over iBGP (internal BGP) and injects the learned routes into the VNet’s routing table via Azure’s software-defined networking (SDN) controller. The key insight: Route Server does not forward data traffic—it only exchanges routing information. Data packets flow directly between NVAs and VMs without passing through Route Server.

Azure Route Server is deployed in a VNet (typically the hub VNet) and assigned a /27 subnet (minimum size). You can deploy one Route Server per VNet, and it supports up to 8 BGP peers (NVAs) per Route Server. Each NVA must be in the same VNet or a peered VNet (within the same region). The Route Server uses its own private IP addresses from the subnet to establish BGP sessions.

Step-by-step mechanism: 1. BGP Peering Establishment: Each NVA initiates a BGP TCP connection (port 179) to the Route Server’s IP. The Route Server acts as a BGP route reflector; it does not originate routes. The NVA must be configured with the Route Server IP as its BGP neighbor, and both sides must use the same ASN. By default, Azure Route Server uses ASN 65515 (a private ASN). You can optionally use a custom ASN. 2. Route Advertisement: The NVA advertises its routes (e.g., on-premises prefixes, other VNet prefixes) to the Route Server via BGP UPDATE messages. The Route Server accepts these routes and stores them in its routing table. 3. Route Reflection: The Route Server reflects the received routes to all other BGP peers (other NVAs) and also programs them into the VNet’s effective routes. This is done via the Azure SDN controller, which updates the route tables of all VMs in the VNet (and peered VNets if configured). 4. Route Withdrawal: If a BGP session goes down (e.g., NVA failure, hold timer expiry), the Route Server removes all routes learned from that peer and updates the VNet’s routes accordingly. The default BGP hold timer is 90 seconds (configurable).

To deploy Azure Route Server via Azure CLI:

# Create a resource group
az group create --name myRG --location eastus

# Create a VNet and subnet for Route Server
az network vnet create --name myVNet -g myRG --location eastus --address-prefix 10.0.0.0/16
az network vnet subnet create --name RouteServerSubnet -g myRG --vnet-name myVNet --address-prefix 10.0.1.0/27

# Create the Route Server
az network routeserver create --name myRouteServer -g myRG --hosted-subnet /subscriptions/.../subnets/RouteServerSubnet --public-ip-address myRouteServerPIP

# Add a BGP peer (NVA)
az network routeserver peering create --name myNVA1 -g myRG --routeserver myRouteServer --peer-ip 10.0.2.4 --peer-asn 65001

# Verify BGP peers
az network routeserver peering list -g myRG --routeserver myRouteServer

# View effective routes on a VM
az network nic show-effective-route-table -g myRG -n myVMNic

A large enterprise deploys two Palo Alto Networks NVAs in an active/active configuration in the hub VNet to inspect traffic between on-premises and Azure. Each NVA advertises the same on-premises prefixes (e.g., 10.0.0.0/8) with different BGP attributes (e.g., MED, AS path). Azure Route Server peers with both NVAs and reflects both routes to the spoke VNets. The VMs in spokes now have two equal-cost paths to on-premises. Azure’s SDN controller performs ECMP (Equal-Cost Multi-Path) routing, distributing traffic across both NVAs. If one NVA fails, its BGP session drops, and Route Server withdraws its routes within 90 seconds (hold timer). Traffic seamlessly shifts to the surviving NVA. In production, we set the BGP hold timer to 30 seconds for faster convergence. One common misconfiguration: forgetting to enable IP forwarding on the NVA's NICs, which prevents the NVA from forwarding traffic between subnets.

A retail company uses Cisco SD-WAN appliances in Azure to connect hundreds of branch offices. Each SD-WAN appliance establishes a BGP session with Azure Route Server and advertises the branch office prefixes (e.g., each /24). Route Server propagates these routes to all spoke VNets hosting application VMs. This eliminates the need for static UDRs per branch. In production, we observed that Route Server can handle up to 10,000 routes, which is sufficient for most enterprises. However, if the SD-WAN appliance advertises too many routes (e.g., /32 host routes), the route table can become bloated. We use route filtering on the NVA to advertise only summary prefixes. A common pitfall: the SD-WAN appliance and Route Server must use the same BGP ASN (or the NVA must have allowas-in enabled) to avoid AS path loop prevention dropping routes.

A financial services firm has an ExpressRoute circuit for primary connectivity and a VPN gateway as backup. They deploy an NVA that peers with both the ExpressRoute gateway (via BGP) and the VPN gateway (via BGP). The NVA learns on-premises routes from ExpressRoute and advertises them to Azure Route Server. Route Server propagates these routes to spoke VNets. When ExpressRoute fails, the NVA withdraws the routes, and Route Server removes them from spoke VNets. The VPN gateway continues to advertise the same prefixes, but with a higher MED, so traffic prefers ExpressRoute. This setup requires careful BGP attribute manipulation on the NVA. A common misconfiguration: the NVA advertises a default route (0.0.0.0/0) to Route Server, which then propagates it to all spokes, causing all internet-bound traffic to hairpin through the NVA, which may not be intended.