🌐 Azure Route Server - Design and Implementation Guide
📋 Overview
Azure Route Server is a fully managed service that enables dynamic routing between your network virtual appliances (NVAs) and your virtual network. It acts as a route reflector, facilitating BGP peering between NVAs and the Azure Software Defined Network (SDN).
🏗️ Architecture Overview
graph TB
subgraph "Azure Virtual Network"
subgraph "RouteServerSubnet (/27)"
RS[Azure Route Server
BGP AS: 65515]
end
subgraph "NVA Subnet"
NVA1[Network Virtual Appliance 1
BGP AS: 65001]
NVA2[Network Virtual Appliance 2
BGP AS: 65002]
end
subgraph "Application Subnet"
VM1[Virtual Machine 1]
VM2[Virtual Machine 2]
end
end
subgraph "On-Premises"
OnPrem[On-Premises Network
BGP AS: 65000]
end
RS -.->|BGP Peering| NVA1
RS -.->|BGP Peering| NVA2
NVA1 -.->|VPN/ExpressRoute| OnPrem
NVA2 -.->|VPN/ExpressRoute| OnPrem
VM1 -->|Route via NVA| NVA1
VM2 -->|Route via NVA| NVA2
style RS fill:#e1f5fe
style NVA1 fill:#f3e5f5
style NVA2 fill:#f3e5f5
style OnPrem fill:#e8f5e8
Architecture Explanation:
- Azure Route Server: Deployed in a dedicated RouteServerSubnet with /27 CIDR, acts as BGP route reflector
- BGP Peering: Establishes BGP sessions between Route Server and NVAs
- Route Advertisement: NVAs advertise on-premises routes to Route Server, which propagates them to Azure SDN
- High Availability: Route Server is deployed in active-active configuration across availability zones
📊 Traffic Flow Scenarios
Scenario 1: East-West Traffic Flow
sequenceDiagram
participant VM1 as VM in Subnet A
participant RS as Route Server
participant NVA as Network Virtual Appliance
participant VM2 as VM in Subnet B
Note over VM1, VM2: East-West Traffic Flow
VM1->>RS: 1. Route lookup for Subnet B
RS->>VM1: 2. Route via NVA (learned from BGP)
VM1->>NVA: 3. Forward packet to NVA
NVA->>NVA: 4. Apply security policies/inspection
NVA->>VM2: 5. Forward to destination VM
VM2->>NVA: 6. Return traffic
NVA->>VM1: 7. Return to source VM
East-West Traffic Flow Explanation:
This diagram shows how traffic flows between VMs in different subnets within the same virtual network. The Route Server learns routes from NVAs via BGP and programs the Azure SDN routing table. When VM1 needs to communicate with VM2, the traffic is routed through the NVA for inspection and policy enforcement.
Scenario 2: North-South Traffic Flow
sequenceDiagram
participant OnPrem as On-Premises
participant NVA as Network Virtual Appliance
participant RS as Route Server
participant VM as Azure VM
Note over OnPrem, VM: North-South Traffic Flow
OnPrem->>NVA: 1. Traffic from on-premises
NVA->>RS: 2. BGP advertisement (on-prem routes)
RS->>RS: 3. Program Azure SDN routes
VM->>RS: 4. Lookup route to on-premises
RS->>VM: 5. Route via NVA
VM->>NVA: 6. Forward to NVA
NVA->>OnPrem: 7. Forward to on-premises
North-South Traffic Flow Explanation:
This sequence shows traffic flow between Azure VMs and on-premises networks. The NVA advertises on-premises routes to Route Server via BGP, which then programs the Azure SDN. Return traffic from Azure VMs to on-premises follows the same path through the NVA.
BGP Route Advertisement Flow
graph LR
subgraph "BGP Route Learning Process"
A[NVA learns routes
from on-premises] --> B[NVA advertises routes
to Route Server via BGP]
B --> C[Route Server receives
BGP advertisements]
C --> D[Route Server programs
Azure SDN routing table]
D --> E[Azure VMs receive
updated routes]
E --> F[Traffic flows via
programmed routes]
end
style A fill:#ffebee
style B fill:#e8f5e8
style C fill:#e3f2fd
style D fill:#fff3e0
style E fill:#f3e5f5
style F fill:#e0f2f1
BGP Route Advertisement Process:
This diagram illustrates how routes are learned and propagated in the Azure Route Server environment. The process ensures that Azure VMs have accurate routing information for reaching on-premises networks through the appropriate NVAs.
🔧 Implementation Command Sequence
Command Execution Order
graph TD
A[1Create Route Server Subnet] --> B[2Create Public IP for Route Server]
B --> C[3Create Route Server Instance]
C --> D[4Configure Route Server Settings]
D --> E[5Create BGP Peering Connections]
E --> F[6Configure NVA BGP Settings]
F --> G[7Verify BGP Sessions]
G --> H[8Test Route Advertisement]
style A fill:#e8f5e8
style B fill:#e3f2fd
style C fill:#fff3e0
style D fill:#f3e5f5
style E fill:#ffebee
style F fill:#e0f2f1
style G fill:#fce4ec
style H fill:#e8eaf6
⚙️ Step-by-Step Configuration
1Create Route Server Subnet
az network vnet subnet create \
--resource-group MyResourceGroup \
--vnet-name MyVNet \
--name RouteServerSubnet \
--address-prefixes 10.0.1.0/27
Parameter Explanation:
- --name RouteServerSubnet: Must be exactly "RouteServerSubnet" (case-sensitive)
- --address-prefixes 10.0.1.0/27: Minimum /27 subnet required (32 addresses)
- Subnet Requirements: Cannot contain any other resources, dedicated to Route Server
Important: The RouteServerSubnet must be created before any other Route Server resources. This subnet is reserved exclusively for Azure Route Server instances and cannot contain any other resources.
2Create Public IP for Route Server
az network public-ip create \
--resource-group MyResourceGroup \
--name RouteServerPublicIP \
--sku Standard \
--allocation-method Static \
--version IPv4
Parameter Explanation:
- --sku Standard: Must be Standard SKU (Basic not supported)
- --allocation-method Static: Static allocation required for Route Server
- --version IPv4: IPv4 addressing (IPv6 not currently supported)
Next Step: The public IP will be associated with the Route Server instance. This IP is used for external BGP peering and management access.
3Create Route Server Instance
az network routeserver create \
--resource-group MyResourceGroup \
--name MyRouteServer \
--hosted-subnet /subscriptions/{subscription-id}/resourceGroups/MyResourceGroup/providers/Microsoft.Network/virtualNetworks/MyVNet/subnets/RouteServerSubnet \
--public-ip-address RouteServerPublicIP
Parameter Explanation:
- --name MyRouteServer: User-defined name for the Route Server instance
- --hosted-subnet: Full resource ID of the RouteServerSubnet
- --public-ip-address: Name or resource ID of the public IP created in step 2
Deployment Time: Route Server creation typically takes 15-20 minutes. The service is deployed in active-active configuration across availability zones for high availability.
4Configure Route Server Settings
az network routeserver update \
--resource-group MyResourceGroup \
--name MyRouteServer \
--allow-b2b-traffic true \
--allow-transit true
Parameter Explanation:
- --allow-b2b-traffic true: Enables branch-to-branch traffic via Route Server
- --allow-transit true: Allows transit routing through NVAs
- Default Values: Both parameters default to false if not specified
Configuration Impact: These settings determine how Route Server handles traffic between different network segments. Branch-to-branch traffic allows connectivity between multiple on-premises sites via Azure.
5Create BGP Peering Connection
az network routeserver peering create \
--resource-group MyResourceGroup \
--routeserver MyRouteServer \
--name NVA-BGP-Peering \
--peer-asn 65001 \
--peer-ip 10.0.2.4
Parameter Explanation:
- --name NVA-BGP-Peering: User-defined name for the BGP peering session
- --peer-asn 65001: BGP Autonomous System Number of the NVA (must be different from 65515)
- --peer-ip 10.0.2.4: Internal IP address of the NVA for BGP peering
BGP Requirements: The NVA must be configured to establish BGP peering with Route Server IP addresses. Route Server uses ASN 65515 by default and cannot be changed.
Additional BGP Peering (High Availability)
az network routeserver peering create \
--resource-group MyResourceGroup \
--routeserver MyRouteServer \
--name NVA2-BGP-Peering \
--peer-asn 65002 \
--peer-ip 10.0.2.5
High Availability Configuration:
- Multiple NVAs: Configure multiple BGP peering sessions for redundancy
- Different ASNs: Each NVA should have a unique ASN
- Load Balancing: Route Server distributes traffic across multiple NVAs
6Verify Route Server Configuration
az network routeserver show \
--resource-group MyResourceGroup \
--name MyRouteServer
Verification Output:
- provisioningState: Should show "Succeeded"
- virtualRouterAsn: Default ASN 65515
- virtualRouterIps: Two IP addresses for HA configuration
7Check BGP Peering Status
az network routeserver peering list \
--resource-group MyResourceGroup \
--routeserver MyRouteServer
Peering Status Verification:
- connectionState: Should show "Connected"
- peerAsn: Confirms configured ASN
- peerIp: Confirms NVA IP address
8View Learned Routes
az network routeserver peering list-learned-routes \
--resource-group MyResourceGroup \
--routeserver MyRouteServer \
--name NVA-BGP-Peering
Route Learning Verification:
- Shows routes learned from NVA: On-premises networks and other advertised routes
- Route attributes: Network prefix, next hop, AS path
- Troubleshooting: Empty results indicate BGP session issues
9View Advertised Routes
az network routeserver peering list-advertised-routes \
--resource-group MyResourceGroup \
--routeserver MyRouteServer \
--name NVA-BGP-Peering
Route Advertisement Verification:
- Shows routes advertised to NVA: Azure subnet routes and connected networks
- Virtual Network Routes: All subnets in the virtual network
- Peered Network Routes: Routes from peered virtual networks
🔄 Route Server Components Relationship
graph TD
subgraph "Component Dependencies"
A[Virtual Network] --> B[RouteServerSubnet /27]
C[Public IP Standard SKU] --> D[Route Server Instance]
B --> D
D --> E[BGP Peering Session 1]
D --> F[BGP Peering Session 2]
G[NVA 1 Config] --> E
H[NVA 2 Config] --> F
E --> I[Route Learning/Advertisement]
F --> I
I --> J[Azure SDN Route Programming]
end
style A fill:#e8f5e8
style B fill:#e3f2fd
style C fill:#fff3e0
style D fill:#f3e5f5
style E fill:#ffebee
style F fill:#ffebee
style G fill:#e0f2f1
style H fill:#e0f2f1
style I fill:#fce4ec
style J fill:#e8eaf6
Component Relationship Explanation:
This diagram shows the dependency chain for Route Server components. Each component must be created in the correct order, with proper dependencies satisfied before proceeding to the next step.
🏃♂️ Complete Deployment Workflow
graph TB
subgraph "Pre-Deployment Phase"
A1[Plan IP Address Space] --> A2[Design Network Topology]
A2 --> A3[Configure NVA Requirements]
end
subgraph "Deployment Phase"
B1[Create RouteServerSubnet] --> B2[Create Public IP]
B2 --> B3[Deploy Route Server]
B3 --> B4[Configure Route Server Settings]
B4 --> B5[Create BGP Peering]
end
subgraph "Configuration Phase"
C1[Configure NVA BGP] --> C2[Establish BGP Sessions]
C2 --> C3[Verify Route Learning]
C3 --> C4[Test Traffic Flow]
end
subgraph "Validation Phase"
D1[Monitor BGP Status] --> D2[Validate Route Tables]
D2 --> D3[Performance Testing]
D3 --> D4[Documentation]
end
A3 --> B1
B5 --> C1
C4 --> D1
style A1 fill:#e8f5e8
style B1 fill:#e3f2fd
style C1 fill:#fff3e0
style D1 fill:#f3e5f5
Deployment Workflow Explanation:
This comprehensive workflow shows all phases of Route Server deployment, from initial planning through validation. Each phase must be completed successfully before proceeding to the next phase.
🔍 Monitoring and Troubleshooting
Monitor Route Server Health
az network routeserver show \
--resource-group MyResourceGroup \
--name MyRouteServer \
--query '{name:name,provisioningState:provisioningState,virtualRouterAsn:virtualRouterAsn,virtualRouterIps:virtualRouterIps}'
Monitor BGP Session Status
az network routeserver peering show \
--resource-group MyResourceGroup \
--routeserver MyRouteServer \
--name NVA-BGP-Peering \
--query '{name:name,connectionState:connectionState,peerAsn:peerAsn,peerIp:peerIp}'
Troubleshooting Common Issues
graph LR
subgraph "Common Issues & Solutions"
A[BGP Session Down] --> A1[Check NVA Configuration]
A --> A2[Verify Network Connectivity]
A --> A3[Check ASN Configuration]
B[Routes Not Learning] --> B1[Verify BGP Advertisement]
B --> B2[Check Route Filters]
B --> B3[Validate IP Addressing]
C[Traffic Not Flowing] --> C1[Check Route Tables]
C --> C2[Verify UDR Configuration]
C --> C3[Validate NSG Rules]
end
style A fill:#ffebee
style B fill:#fff3e0
style C fill:#e8f5e8
Troubleshooting Guide:
This diagram outlines common issues encountered with Route Server deployments and their typical resolution paths. Most issues stem from configuration mismatches between Route Server and NVA BGP settings.
📈 Best Practices and Recommendations
🎯 Key Best Practices
- High Availability: Deploy multiple NVAs with BGP peering for redundancy
- IP Planning: Reserve sufficient IP space for RouteServerSubnet expansion
- BGP Configuration: Use private ASNs (64512-65534) for NVAs
- Monitoring: Implement continuous monitoring of BGP sessions
- Documentation: Maintain detailed network topology documentation
⚠️ Important Limitations
- Subnet Requirement: RouteServerSubnet must be exactly /27 or larger
- BGP ASN: Route Server uses ASN 65515 (cannot be changed)
- Route Limits: Maximum 1000 routes per BGP peering session
- Region Availability: Not available in all Azure regions