Azure Route Server

Azure Route Server is a fully managed service that acts as a BGP route reflector inside your hub VNet — it exchanges routes dynamically between your Network Virtual Appliances (NVAs) and Azure’s software-defined network, eliminating the need to manually maintain User Defined Routes every time your network topology changes.

The Problem It Solves

Without Route Server, every time an NVA learns a new route (a new branch office, a new subnet, a new peer) you had to manually update UDR tables on every spoke subnet:

Old approach — manual UDR maintenance:
  NVA learns new branch: 192.168.50.0/24
        ↓
  Engineer must manually add UDR to:
    - Spoke 1 subnet A route table
    - Spoke 1 subnet B route table
    - Spoke 2 subnet A route table
    - Spoke 2 subnet B route table
    - ... every subnet in every spoke
  Miss one → black hole routing → outage
With Route Server:
  NVA advertises 192.168.50.0/24 via BGP to Route Server
        ↓
  Route Server automatically programs the route
  into effective routes of all peered spoke VNets
        ↓
  Done — zero manual intervention

How BGP Exchange Works — Step by Step

Step 1 — Route Server deploys into RouteServerSubnet

Route Server requires a dedicated subnet named exactly RouteServerSubnet with a minimum /27:

Hub VNet: 10.0.0.0/16
  RouteServerSubnet: 10.0.6.0/27
    → Route Server Instance 0: 10.0.6.4
    → Route Server Instance 1: 10.0.6.5
    → Virtual IP (peering):    10.0.6.6

Route Server always deploys as two instances for high availability, both in the same subnet. Azure assigns them IPs automatically. Both instances must be peered with your NVA — you peer with each IP individually.

Route Server always uses ASN 65515 — this is fixed and cannot be changed.

Step 2 — NVA establishes eBGP sessions with both instances

Your NVA (Cisco CSR, Palo Alto VM-Series, Fortinet FortiGate, etc.) opens two BGP sessions — one to each Route Server instance. This is standard external BGP (eBGP) — the NVA and Route Server are in different ASNs:

NVA (ASN 65001) ←—eBGP—→ Route Server Instance 0 (ASN 65515, 10.0.6.4)
NVA (ASN 65001) ←—eBGP—→ Route Server Instance 1 (ASN 65515, 10.0.6.5)

Configuration on a Cisco CSR NVA:

router bgp 65001
  bgp router-id 10.0.4.4
  bgp log-neighbor-changes
  ! Peer with Route Server instance 0
  neighbor 10.0.6.4 remote-as 65515
  neighbor 10.0.6.4 ebgp-multihop 2
  neighbor 10.0.6.4 soft-reconfiguration inbound
  ! Peer with Route Server instance 1
  neighbor 10.0.6.5 remote-as 65515
  neighbor 10.0.6.5 ebgp-multihop 2
  neighbor 10.0.6.5 soft-reconfiguration inbound
  ! Advertise on-premises routes learned from VPN
  network 192.168.0.0 mask 255.255.0.0
  network 172.16.0.0 mask 255.255.0.0

The ebgp-multihop 2 is required because the NVA and Route Server are not directly connected at Layer 2 — they communicate over the VNet fabric.

Step 3 — NVA advertises routes to Route Server

The NVA tells Route Server about routes it knows — on-premises prefixes learned via VPN tunnels, SD-WAN routes, or any custom prefixes:

NVA → Route Server:
  ADVERTISE 192.168.0.0/16   (on-premises HQ network)
  ADVERTISE 172.16.0.0/12    (branch offices)
  ADVERTISE 10.100.0.0/16    (SD-WAN overlay)

Route Server accepts these advertisements and stores them.

Step 4 — Route Server programs spoke VNet effective routes

Route Server takes the NVA-advertised routes and automatically injects them into the effective routes of every peered spoke VNet — no UDR required:

Spoke 1 VM effective routes (auto-programmed):
  10.0.0.0/16      → VNet local
  10.1.0.0/16      → VNet local
  192.168.0.0/16   → 10.0.4.4 (NVA primary)   ← from Route Server
  172.16.0.0/12    → 10.0.4.4 (NVA primary)   ← from Route Server
  10.100.0.0/16    → 10.0.4.4 (NVA primary)   ← from Route Server
  0.0.0.0/0        → Internet

When a spoke VM sends traffic to 192.168.10.5 (an on-premises host), the effective route points it to the NVA, which forwards it through the appropriate VPN tunnel.

Step 5 — Route Server advertises Azure routes back to NVA

The exchange is bidirectional. Route Server tells the NVA about Azure VNet address spaces:

Route Server → NVA:
  ADVERTISE 10.0.0.0/16   (hub VNet)
  ADVERTISE 10.1.0.0/16   (spoke 1 VNet)
  ADVERTISE 10.2.0.0/16   (spoke 2 VNet)
  ADVERTISE 10.3.0.0/16   (spoke 3 VNet)

The NVA now knows all Azure prefixes and can route on-premises traffic destined for Azure correctly through its VPN tunnels — without anyone manually configuring static routes on the NVA.

Branch-to-Branch — The Key Feature

When branch-to-branch is enabled on Route Server, it becomes a route reflector between VPN Gateway and NVA, allowing on-premises sites to reach each other through Azure:

Branch A (192.168.1.0/24) ←—VPN—→ VPN Gateway
                                         ↕  BGP
                                    Route Server
                                         ↕  BGP
Branch B (192.168.2.0/24) ←—VPN—→ NVA
With branch-to-branch ENABLED:
  Route Server reflects Branch A routes → NVA → Branch B
  Route Server reflects Branch B routes → VPN GW → Branch A
  Result: Branch A can reach Branch B through Azure hub

This is how Azure Route Server enables transit routing — Azure becomes the backbone connecting your branch offices, without needing a separate SD-WAN overlay.

# Enable branch-to-branch
az network routeserver update \
  --resource-group rg-hub-network \
  --name hub-route-server \
  --allow-b2b-traffic true

Active-Active NVA Pattern

Route Server is the enabler for active-active NVA deployments — both NVA instances advertise the same routes, and Route Server programs both next-hops into spoke effective routes using ECMP (Equal-Cost Multi-Path):

Both NVAs advertise: 192.168.0.0/16
Spoke VM effective routes:
  192.168.0.0/16 → 10.0.4.4 (NVA primary)    ← ECMP
  192.168.0.0/16 → 10.0.4.5 (NVA secondary)  ← ECMP
Traffic load-balanced across both NVAs
If one NVA fails → BGP session drops →
Route Server withdraws that next-hop →
All traffic shifts to remaining NVA automatically

This gives you sub-second failover without any manual intervention — the BGP hold-down timer (typically 90 seconds, tunable to as low as 1 second with BFD) triggers automatic route withdrawal.

RouteServerSubnet Requirements

The restriction on NSGs and UDRs on the RouteServerSubnet is intentional — Azure manages all routing within this subnet internally, and applying UDRs would break the BGP sessions.

Route Server vs Manual UDRs — When to Use Each

Route Server shines when you have a third-party NVA with dynamic routing requirements. If your hub uses only Azure Firewall (which does not speak BGP), stick with UDRs — Route Server adds no value without a BGP-capable NVA to peer with.

Key Limits

The 1,000 route limit per NVA is important for large enterprises with many branch offices — if you have more than 1,000 prefixes, use route summarisation on the NVA before advertising to Route Server.

Key Takeaway

Azure Route Server is the dynamic routing backbone of a hub and spoke network containing third-party NVAs. It replaces fragile, manually maintained UDR tables with automated BGP route exchange — the NVA advertises what it knows, Route Server programs every spoke automatically, and the whole network converges in seconds when topology changes. Combined with active-active NVAs and branch-to-branch enabled, it gives you a carrier-grade routing infrastructure entirely within Azure.