What is Azure Route Server? How does it work?

In the previous post we learned about the system routes and the user defined routes. System routes come by default as part of each subnet while the User Defined routes need to be manually configured to point the traffic to a Network Virtual Appliance created inside the VNET. 

This NVA( network virtual appliance) could be a firewall, a router, a Load Balancer etc. from any third-party vendor like Cisco, Palo Alto, F5 etc. When we define UDRs in a subnet it is like adding the static routes if we want to relate Software Defined Networking construct with traditional networking. So, defining & managing these UDRs can be a cumbersome task.

To ease this task, Azure offers another service known as Azure Route Server (ARS). ARS simplifies the route exchange between a VNET and NVA using dynamic routing protocols like Border Gateway Protocol (BGP) thus eliminating the need of manually configuring and maintaining the route tables.

Understanding Azure Route Server

Azure route server is a fully managed service from Azure & it also provides us with high availability. It supports zone level redundancy if ARS is deployed in an Azure region that supports availability zones.

You can only have a single ARS within a VNET and Azure route server requires a dedicated subnet within a VNET.

If a VNET with route server deployed is peered to another VNET via VNET peering and we have checked box, the “Use the remote virtual network’s gateway or Route Server” on second VNET then the ARS also learns the prefixes form the peered VNET and advertises these prefixes to the NVAs with which it is dynamically exchanging the routes. And it also advertises the routes received from NVAs to the peered virtual networks.

A point to note is that Azure Route Server only helps in exchange of route information (Control Plane) & doesn’t participate in the data plane i.e., the data traffic goes via the NVAs directly to destination VMs and vice-versa.

How does it work?

The Azure Route Server’s functioning with a virtual network’s SDWAN NVA and security NVA is depicted in the diagram below:

Once the BGP peering is established, an on-premises route (10.10.0.0/16) is received from the SDWAN appliance and a default route (0.0.0.0/0) is received from the firewall. The VMs in the virtual network are configured with these routes automatically, which directs all traffic intended for the on-premises network to the SDWAN appliance, and all Internet-bound traffic intended to the firewall. 

The virtual network address (10.0.2.0/28) will be sent to both NVAs by the ARS in the opposite direction. The SDWAN appliance then distributes it to the on-site network.

Azure Route Server Benefits

• The Azure Route Server makes it easier to configure, manage, and ideploy your NVA within your virtual network. 
• There is no need for manual routing table updates on your NVA when there are changes made to your virtual network addresses.
• No manual updates of User-Defined Routes needed  for the announcement of new or the withdrawal of old routes.
• Multiple instances of your NVA can be peered using Azure Route Server.

Azure Route Server Limitations

• Maximum BGP peers supported is 8.
• Maximum Number of routes each BGP peer can advertise to ARS is 1000. If this limit is breached the BGP session is dropped.
• Maximum number of VMs supported by Azure route server is 4000.
• Azure route server only supports BGP as dynamic routing protocol
• It supports only 2-byte ASNs in BGP.
• The ASN chosen for NVA must be different that none for Route Server.
• Azure route server doesn’t support IPV6 currently.
• A public IP is required for Azure route server to maintain communication with backend service that manages Route server configuration.