Troubleshoot Azure Route Server issues
Learn how to troubleshoot some of the common Azure Route Server issues.
Connectivity issues
Why does my network virtual appliance (NVA) lose internet connectivity after it advertises the default route (0.0.0.0/0) to the Route Server?
When your NVA advertises the default route, the Route Server programs it for all the virtual machines (VMs) in the virtual network including the NVA itself. This default route sets the NVA as the next hop for all internet-bound traffic. If your NVA needs internet connectivity, you need to configure a user-defined route (UDR) to override this default route from the NVA and attach the UDR to the subnet where the NVA is hosted. Otherwise, the NVA host machine keeps sending the internet-bound traffic including the one sent by the NVA back to the NVA itself. For more information, see user-defined routes.
| Route | Next hop |
|---|---|
| 0.0.0.0/0 | Internet |
Why does the NVA lose its connectivity to the Route Server after forcing all traffic to a firewall using a user-defined route (UDR) on the GatewaySubnet?
If you want to inspect your on-premises traffic using a firewall, you can force all on-premises traffic to the firewall using a user-defined route (UDR) on the GatewaySubnet (a route table associated to the GatewaySubnet that has the UDR). However, this UDR may break the communication between the Route Server and the gateway by forcing their control plane traffic (BGP) to the firewall (this issue occurs if you're inspecting the traffic destined to the virtual network that has the Route Server). To avoid this issue, you need to add another UDR to the GatewaySubnet route table to exclude control plane traffic from being forced to the firewall (in case adding a BGP rule to the firewall is not desired/possible):
| Route | Next hop |
|---|---|
| 10.0.0.0/16 | 10.0.2.1 |
| 10.0.1.0/27 | VirtualNetwork |
10.0.0.0/16 is the address space of the virtual network and 10.0.1.0/27 is the address space of RouteServerSubnet. 10.0.2.1 is the IP address of the firewall.
Why can't I TCP ping from my NVA to the BGP peer IP of the Route Server after I set up the BGP peering between them?
In some NVAs, you need to add a static route to the Route Server subnet to be able to TCP ping the Route Server from the NVA and to avoid BGP peering flapping. For example, if the Route Server is in 10.0.255.0/27 and your NVA is in 10.0.1.0/24, you need to add the following route to the routing table in the NVA:
| Route | Next hop |
|---|---|
| 10.0.255.0/27 | 10.0.1.1 |
10.0.1.1 is the default gateway IP in the subnet where your NVA (or more precisely, one of the NICs) is hosted.
Why do I lose connectivity to my on-premises network over ExpressRoute and/or Azure VPN when I'm deploying a Route Server to a virtual network that already has ExpressRoute gateway and/or Azure VPN gateway?
When you deploy a Route Server to a virtual network, we need to update the control plane between the gateways and the virtual network. During this update, there's a period of time when the VMs in the virtual network lose connectivity to the on-premises network. We strongly recommend that you schedule maintenance to deploy a Route Server in your production environment.
Control plane issues
Why does my on-premises network connected to Azure VPN gateway not receive the default route advertised by the Route Server?
Although Azure VPN gateway can receive the default route from its BGP peers including the Route Server, it doesn't advertise the default route to other peers.
Why does my NVA not receive routes from the Route Server even though the BGP peering is up?
The ASN that the Route Server uses is 65515. Make sure you configure a different ASN for your NVA so that an eBGP session can be established between your NVA and Route Server so route propagation can happen automatically. Make sure you enable "multi-hop" in your BGP configuration because your NVA and the Route Server are in different subnets in the virtual network.
The BGP peering between my NVA and Route Server is up. I can see routes exchanged correctly between them. Why aren’t the NVA routes in the effective routing table of my VM?
If your VM is in the same virtual network as your NVA and Route Server:
Route Server exposes two BGP peer IPs, which are hosted on two VMs that share the responsibility of sending the routes to all other VMs running in your virtual network. Each NVA must set up two identical BGP sessions (for example, use the same AS number, the same AS path and advertise the same set of routes) to the two VMs so that your VMs in the virtual network can get consistent routing info from Azure Route Server.
If you have two or more instances of the NVA, you can advertise different AS paths for the same route from different NVA instances if you want to designate one NVA instance as active and the other passive.
If your VM is in a different virtual network than the one that hosts your NVA and the Route Server. Check if VNet Peering is enabled between the two VNets and if Use Remote Route Server is enabled on your VM's virtual network.
Why is the Equal-Cost Multi-Path (ECMP) function of my ExpressRoute turned off after I deploy Route Server to the virtual network?
When you advertise the same routes from your on-premises network to Azure over multiple ExpressRoute connections, normally ECMP is enabled by default for the traffic destined for these routes from Azure back to your on-premises network. Currently, when you deploy the Route Server, multiple-path information is lost in the BGP exchange between ExpressRoute and the Route Server, and consequently traffic from Azure will traverse only on one of the ExpressRoute connections.
Next step
To learn how to create and configure Azure Route Server, see:
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for