- What ARS does and where it sits in a network.
- When and why to use ARS (including a common AVS example).
- Deployment considerations, sample commands, and a short BGP sample to get started.
Architecture overview
Typical ARS placement and flow:- Azure Route Server (ARS) is deployed in a dedicated subnet within a virtual network.
- On-premises networks connect via SD‑WAN or ExpressRoute and peer to ARS using BGP.
- Internet-facing devices (firewalls/NVAs) also peer with ARS using BGP.
- Application VMs in their own subnets receive learned routes via ARS so their effective routes point to the correct next-hop (on‑prem via SD‑WAN/ExpressRoute, internet via firewall, or local Azure resources).
A common real-world example (Azure VMware Solution)
Azure VMware Solution (AVS) often uses ExpressRoute and advertises its routes via BGP. If you also have a central hub ExpressRoute (or a region without global reach), ARS can bridge route exchange:- ARS peers with BGP-capable NVAs and learns routes from on‑premises or AVS (advertised over ExpressRoute/SD‑WAN).
- ARS then advertises those learned routes to other appliances and the VNet.
- Result: routes from AVS and on‑premises propagate to each other without manual route configuration.
Key benefits and behaviors
- Automated BGP route exchange between NVAs and VNets — reduces manual UDR management.
- Fast adaptation to network changes — if a primary path fails (for example, a firewall), ARS updates learned routes to direct traffic to the backup.
- Requires appliances that support BGP; ARS cannot peer with non-BGP devices.
Network appliances (firewalls, SD‑WAN devices, NVAs) that peer with Azure Route Server must support BGP. Confirm BGP capability and configuration details with your vendor before deployment.
User‑defined routes (UDRs) and Azure route priority rules can override routes learned via ARS. Always validate effective routes for subnets after deployment to avoid unexpected traffic flows.
Deployment prerequisites and recommendations
| Requirement | Why it matters | Example/Notes |
|---|---|---|
| Dedicated subnet | ARS requires its own subnet (AzureRouteServerSubnet) in the VNet | Do not host other resources in this subnet |
| BGP-capable peers | Peers must support BGP to exchange routes | Firewalls, SD‑WAN appliances, NVAs |
| Plan ASNs & IPs | Predefine Autonomous System Numbers and peering IPs | Use unique ASNs per peer where needed |
| Monitoring & validation | Verify route propagation and effective routes | Use Network Watcher, route table diagnostics, and peer appliance logs |
Quick examples
Azure CLI: create a Route Server and a peering (example)- Replace ASNs and IPs with your planned values.
- Many appliances require additional settings (e.g., BFD, route-maps); consult the vendor guide.
Monitoring and validation
- Use Azure Network Watcher and the “Effective routes” view on NICs to confirm ARS-learned routes reach application subnets.
- Monitor BGP session status on the appliance and view route tables on ARS to ensure expected prefixes are learned and advertised.
- Test failover scenarios to validate automatic route updates.
Summary
Azure Route Server brings dynamic, enterprise-grade BGP routing into Azure as a managed service. It reduces manual route updates, simplifies failover handling, and allows easier integration of on‑premises networks and BGP-capable appliances with your VNets. As environments scale in complexity, ARS centralizes routing decisions and reduces operational overhead.