Azure Route Tables in a nutshell

You probably hear the word ‘route’ all the time as a network engineer. But what does it actually mean? A route is simply a direction. It tells a network packet to go from one IP address to another.

In this short post, I’ll explain the differences between Azure’s default routes and user-defined routes (UDRs), and show you how to set up UDRs.
Whenever you create a new Azure VNet, Azure automatically makes a route table for each subnet in the network.

A brief overview of Azure routes.

A route table acts as a guide for directing network traffic. For instance, if a Virtual Machine needs to reach another destination, it checks the route table to find out where to go next.
The route table tells the Virtual Machine what to do next to reach its destination.
Azure’s default route table has several system routes you can’t change or delete. But you can create your own custom routes, called User Defined Routes (UDRs), to override the defaults. You can also change or remove these custom routes whenever you want.

User-defined routes help Azure VNet network engineers control how traffic moves through the network. By setting up custom routes, you can direct traffic through certain subnets or virtual appliances, giving you more control. In this example, a route table is connected to an Azure VNet subnet, so it affects the network interface cards (NICs) in that subnet.

Azure system-defined routes are built-in rules that automatically direct network traffic. They let resources connect, access the internet, and stay secure without extra setup. This way, you can focus on building and running your apps.

When traffic leaves a subnet, Azure selects a route using the longest-prefix match algorithm on the destination IP address. For example, if a route table has two routes—one for 192.168.0.0/24 and one for 192.168.0.0/16—Azure checks both.

Azure sends traffic for 192.168.0.5 to the next hop set in the 192.168.0.0/24 route. This is because 192.168.0.0/24 is a longer prefix than 192.168.0.0/16, even though 192.168.0.5 matches both routes.

Azure sends traffic for 192.168.1.5 to the next hop defined in the 192.168.0.0/16 route. This is because 192.168.1.5 is not included in 192.168.0.0/24, so 192.168.0.0/16 is the longest matching prefix.

If multiple routes have the same address prefix, Azure decides which route to use based on this order: user-defined routes come first, then BGP routes, and finally system routes.

From the Azure Portal “All services” menu, select Categories {Networking} – {Route tables}

Now I need to enter all required details, then select Create.

1. First, type the route table Name
2. Select a valid Azure Subscription
3. Select an existing or create a new Resource Group
4. Select a Location to deploy the route table

Add A Route

A few seconds later, from the Route table, left main blade select Settings – Routes – + Add

1. Enter a Route name
2. Type the Address prefix, e.g. 0.0.0.0/0 (0.0.0.0/0 means all possible VM IP’s)   
3. Select the Next hop type, e.g. Virtual appliance (as virtual appliance, we mean the Azure Firewall)
4. Enter the Next hop address, e.g. 10.0.5.10 (this is the Azure Firewall internal IP) 

Associate Route Table With A Subnet VNet

The last step is to connect the route table to a subnet in the virtual network. Once this connection is established, the route table will be linked to the virtual network (VNet) and direct all outbound traffic from the subnet’s virtual machines to the Azure Firewall.