Route Tables and Route Priorities

Azure Routing: Mastering Route Tables and Route Priorities

Introduction: Why Routing Matters in the Cloud

When you build a network in Azure, you are essentially creating a virtual landscape of interconnected resources. By default, Azure handles the movement of traffic between your virtual machines, subnets, and the internet through a set of predefined system routes. While these system routes are sufficient for basic deployments, enterprise-grade applications often require granular control over how data packets travel through the network. This is where Route Tables and Route Priorities come into play.

Routing is the process of selecting paths in a network along which to send network traffic. In Azure, routing is not just about connectivity; it is about security, compliance, and performance. If you need to force traffic through a firewall for inspection before it reaches the internet, or if you need to direct traffic between subnets through a specific virtual appliance, you must understand how to override Azure's default routing behavior.

Understanding route tables is essential for any cloud engineer. Misconfigured routing is one of the most common causes of connectivity issues, latency problems, and security vulnerabilities. By mastering how Azure evaluates routes and how you can influence that evaluation, you gain the ability to design networks that are not only functional but also predictable, secure, and easy to maintain as your infrastructure scales.

The Foundation: Understanding Azure System Routes

Before diving into custom route tables, it is critical to understand what Azure does automatically. Every subnet you create in a Virtual Network (VNet) is automatically associated with a set of system routes. These routes ensure that resources within the same VNet can communicate with each other, and that resources can reach the internet if they have a public IP address.

Azure creates these system routes by default:

• VNet Local: Traffic between resources within the same virtual network.
• On-premises: Traffic directed to your local network via a VPN gateway or ExpressRoute.
• Internet: Traffic directed to the public internet.
• Service Tags: Traffic directed to specific Azure services like Storage or SQL Database.

You cannot delete these system routes, but you can override them. When you create a custom route table and associate it with a subnet, the routes in that table are added to the system routes. If a custom route has the same destination prefix as a system route, the custom route takes precedence. This is the fundamental mechanism that allows you to steer traffic according to your specific requirements.

Anatomy of a Route Table

A route table consists of a collection of individual routes. Each route is a simple instruction set that tells Azure where to send a packet based on its destination. A route contains four primary components:

1. Name: A unique identifier for the route within the route table.
2. Address Prefix: The destination IP range (CIDR block) to which this route applies.
3. Next Hop Type: The mechanism used to deliver the traffic.
4. Next Hop Address: The specific IP address of the device (if applicable) that should receive the traffic.

Next Hop Types

When defining a route, the "Next Hop Type" is the most important configuration. It dictates the path the traffic will take. The available types are:

• Virtual Network: Traffic stays within your virtual network.
• Virtual Network Gateway: Traffic is sent to a VPN or ExpressRoute gateway.
• Internet: Traffic is sent to the public internet.
• Virtual Appliance: Traffic is sent to a specific IP address, usually a firewall or a load balancer.
• None: Traffic is dropped. This is useful for black-holing malicious or unwanted traffic.

Callout: The Power of the "Virtual Appliance" Hop The "Virtual Appliance" next hop type is the cornerstone of network security in Azure. By setting this hop type, you can force traffic destined for the internet or another subnet to pass through a Network Virtual Appliance (NVA) such as a Palo Alto firewall, Fortinet, or an Azure Firewall. This allows you to inspect, filter, and log traffic at the packet level, ensuring that you meet strict compliance requirements.

How Azure Evaluates Route Priorities

Azure does not simply look at the first route it finds. It follows a specific, deterministic process to determine the best path for a packet. Understanding this hierarchy is the key to troubleshooting routing issues effectively.

The Longest Prefix Match Rule

The most important rule in IP routing is the "Longest Prefix Match." When a packet arrives, Azure compares the destination IP address against all available routes (both system and custom). If multiple routes match the destination, Azure selects the route with the most specific prefix.

For example, if you have one route for 10.0.0.0/16 and another for 10.0.1.0/24, and a packet is destined for 10.0.1.5, Azure will choose the 10.0.1.0/24 route because it is more specific. This allows you to create broad, general rules while carving out exceptions for specific subnets or services.

Route Priority Hierarchy

Beyond the prefix length, there is an implicit order of precedence that Azure follows:

1. User-Defined Routes (UDRs): These take precedence over everything else. If you create a custom route table, those routes are checked first.
2. BGP Routes: If you are connected to an on-premises network via ExpressRoute or VPN with BGP enabled, these routes are considered next.
3. System Routes: These are the default routes provided by Azure.

Warning: The "Next Hop" Trap A common mistake is creating a custom route with a next hop type of "Virtual Appliance" without ensuring the appliance is actually configured to forward that traffic. If you point traffic to an NVA but the appliance's own routing table doesn't know where to send it, the traffic will be dropped. Always verify that your NVA has "IP Forwarding" enabled on its network interface.

Step-by-Step: Creating and Applying a Route Table

Let's walk through the process of creating a route table and associating it with a subnet using the Azure CLI. This is a common task for network administrators who need to force internet traffic through a centralized firewall.

Step 1: Create the Route Table

First, you define the route table resource.

az network route-table create \
  --name MyRouteTable \
  --resource-group MyResourceGroup \
  --location eastus

Step 2: Create a Custom Route

Next, you add a route to the table. In this example, we are forcing all traffic destined for the internet (0.0.0.0/0) to go through a virtual appliance at 10.0.2.4.

az network route-table route create \
  --resource-group MyResourceGroup \
  --route-table-name MyRouteTable \
  --name ForceTrafficToFirewall \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.2.4

Step 3: Associate the Route Table with a Subnet

Finally, you must link the route table to a specific subnet for it to take effect. Note that a route table can be associated with multiple subnets, but a subnet can only have one route table associated with it.

az network vnet subnet update \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --name MySubnet \
  --route-table MyRouteTable

Advanced Routing Scenarios

Forcing Traffic to On-Premises

Sometimes you need to ensure that all traffic from your cloud environment flows through your corporate data center for centralized logging or security inspection. You can achieve this by creating a route for 0.0.0.0/0 with a next hop type of VirtualNetworkGateway. This effectively directs all internet-bound traffic through your VPN or ExpressRoute connection.

Implementing "Hub and Spoke" Routing

In a hub-and-spoke topology, you have a central "Hub" VNet that contains shared services like firewalls and gateways, and "Spoke" VNets that host applications. To route traffic between spokes, you must use a combination of VNet Peering and UDRs. By setting a UDR in the spokes that points to the firewall in the hub, you ensure that inter-spoke traffic is inspected by the hub's security stack.

Using Service Tags

Azure provides "Service Tags" to simplify routing for common Azure services. Instead of manually updating your route tables whenever an Azure service changes its IP address range, you can use a Service Tag (e.g., Storage, Sql, KeyVault). Azure automatically manages the underlying IP ranges associated with these tags, saving you from constant maintenance.

Tip: Use Service Tags instead of IP Ranges Whenever possible, use Service Tags in your UDRs. They reduce the administrative burden of tracking Azure's frequently changing public IP addresses and make your route tables much easier to read and manage.

Troubleshooting Routing Issues

Even with a solid design, routing problems occur. When you suspect a routing issue, the first step is to isolate where the packet is failing.

Using "Effective Routes"

Azure provides a powerful diagnostic tool called "Effective Routes." You can view these for any network interface (NIC) attached to a virtual machine. This view shows you exactly which routes are currently active, including the combination of system routes, UDRs, and BGP routes.

To view effective routes in the Azure Portal:

1. Navigate to your Virtual Machine.
2. Select Networking in the left menu.
3. Click on the network interface.
4. Select Effective routes in the left menu.

This list will show you the "Next Hop" for every destination. If you see a route that you didn't expect, or if the "Next Hop" is set to an appliance that is currently offline, you have found your problem.

Troubleshooting Checklist

• Is IP Forwarding enabled? If you are using a Virtual Appliance, ensure the "Enable IP forwarding" setting is turned on for the network interface of the appliance.
• Are there conflicting UDRs? Check if you have multiple UDRs overlapping in a way that creates a routing loop.
• Is the UDR associated? A common mistake is creating a route table but forgetting to associate it with the subnet. Check the "Subnets" blade of your route table to confirm associations.
• Is the Gateway propagating routes? If you are using BGP, check if "Gateway Route Propagation" is enabled on the route table. This is required if you want your UDRs to inherit routes from your on-premises network.

Comparison Table: Route Types

Best Practices for Enterprise Environments

Managing routing at scale requires discipline. As your environment grows, you will find that a "wild west" approach to route tables leads to unmanageable complexity. Follow these best practices to keep your network healthy:

1. Centralize Route Management

Avoid creating route tables for every individual subnet. Instead, create a standardized set of route tables and apply them across similar subnets. For example, have a "Tier-1-Web" route table, a "Tier-2-App" route table, and a "Tier-3-Data" route table. This makes auditing and updating much easier.

2. Document Your Traffic Flows

Routing is the "wiring" of your cloud. Use architecture diagrams to document exactly how traffic flows from the internet to your application and back. If you have complex routing, use tags on your route tables to indicate their purpose (e.g., Environment: Prod, Role: Firewall-Redirect).

3. Test in Non-Production

Never apply a new route table to a production subnet without testing it in a development or staging environment. A single typo in an IP address or a misconfigured next hop can cause an immediate, total outage for all resources in that subnet.

4. Leverage Infrastructure as Code (IaC)

Manual configuration in the Azure Portal is prone to human error. Use Terraform, Bicep, or ARM templates to define your route tables. This ensures that your network configuration is version-controlled, reproducible, and can be reviewed by your team before deployment.

5. Monitor for "Next Hop" Health

If you are routing traffic through a third-party appliance, monitor the health of that appliance. If the appliance goes down, your traffic will be dropped. You should have health probes or monitoring alerts that trigger if your NVA becomes unresponsive.

Common Pitfalls and How to Avoid Them

The "Default Route" Loop

A common error is creating a route that points traffic back to the source. For example, if you have a subnet that sends all traffic to a firewall, and the firewall is configured to send all traffic back to that same subnet, you have created a routing loop. The packet will bounce between the two until its Time-To-Live (TTL) expires. Always ensure your firewall has a clear, distinct path to the destination that does not involve looping back to the originating subnet.

Ignoring Gateway Route Propagation

Many engineers forget to enable "Gateway Route Propagation" on their route tables. When this is disabled, the route table ignores any routes learned via BGP from your on-premises network. This often leads to "why can't my VM reach the data center?" support tickets. If you are using a hybrid cloud setup, ensure this setting is enabled for any subnet that needs to talk to on-premises resources.

Over-complicating the Routing Table

Don't create a custom route if a system route already does the job. Each custom route adds complexity and increases the surface area for errors. Only create a UDR when you absolutely need to override the default Azure behavior, such as forcing traffic through an NVA or blocking specific traffic.

The "Public IP" Misconception

A common misconception is that a UDR can override the need for a Public IP address on a VM. It cannot. A UDR only tells the packet where to go. If a packet reaches the internet gateway but the VM doesn't have a public IP (or an outbound NAT rule), the packet will be dropped. Always ensure you have the appropriate NAT or Public IP configuration in addition to your routing logic.

Deep Dive: How Azure Processes Traffic (The Packet Lifecycle)

To truly understand routing, it helps to visualize the lifecycle of a packet. When a packet originates from a VM, it hits the virtual switch inside the Azure host. The host checks the route table associated with the subnet. It performs the "Longest Prefix Match" against all system and user-defined routes.

If the next hop is "Internet," the packet is passed to the Azure internet gateway. If the next hop is an IP address (like an NVA), the packet is encapsulated and sent to that specific IP address. The NVA then receives the packet, strips the encapsulation, and makes its own routing decision.

This lifecycle is why "IP Forwarding" is so critical. By default, Azure virtual machines are configured to only receive traffic destined for their own IP address. If an NVA receives a packet destined for a different server, it will drop it unless IP Forwarding is enabled. Enabling this setting tells the Azure networking stack to ignore the destination IP check and allow the VM to process packets destined for other addresses.

The Role of Network Security Groups (NSGs) vs. Route Tables

A frequent source of confusion is the difference between Route Tables and Network Security Groups (NSGs). It is important to distinguish between the two:

• Route Tables dictate the path the traffic takes (the "where").
• NSGs dictate whether the traffic is allowed to pass (the "if").

Think of a Route Table as a GPS navigation system for your packet, and an NSG as a security guard at the door. Even if your route table tells the packet to go to a specific server, the NSG can block it at the destination interface. You need both to build a secure and functional network. Always check your NSG rules if you have confirmed that your routing is correct but traffic is still not flowing.

Summary Checklist for Routing Design

When you are tasked with designing a new VNet or updating an existing one, use this checklist to ensure your routing is robust:

1. Define Requirements: Do you need to force traffic through a firewall? Do you need to connect to an on-premises network?
2. Audit System Routes: Look at the default routes to see if they already meet your needs.
3. Draft UDRs: Create your custom routes, ensuring you use the most specific prefixes possible.
4. Check Dependencies: Does your next hop (NVA or Gateway) have the necessary permissions (IP Forwarding) and connectivity?
5. Configure NSGs: Ensure your security rules allow the traffic that your routes are directing.
6. Validate: Deploy to a non-production environment and use the "Effective Routes" tool to verify the path.
7. Monitor: Set up alerts for NVA health and connectivity to ensure your routing path remains available.

Key Takeaways

1. System Routes are the Baseline: Azure provides default routes for VNet, internet, and on-premises connectivity; you only need to create custom route tables when you need to override these defaults.
2. Longest Prefix Match is Rule #1: Azure always selects the most specific IP prefix when evaluating multiple matching routes. This is the primary mechanism for overriding system behavior.
3. UDRs Provide Granular Control: Use User-Defined Routes to force traffic through virtual appliances, block specific IP ranges, or direct traffic to specific gateways.
4. IP Forwarding is Mandatory for NVAs: If you are using a virtual machine as a firewall or router, you must enable IP forwarding on its network interface, or your traffic will be dropped.
5. NSGs and Route Tables are Partners: Routing defines the path, while security groups define the access. You must configure both correctly to achieve a working network topology.
6. Use Effective Routes for Troubleshooting: The "Effective Routes" view in the Azure Portal is your best friend when diagnosing why traffic isn't flowing where you expect it to.
7. Infrastructure as Code is Essential: Avoid manual portal updates for complex routing; use Terraform or Bicep to maintain a version-controlled, repeatable network configuration.

By internalizing these concepts, you transition from someone who simply "creates" networks to a network architect who can design, implement, and maintain highly secure and efficient cloud environments. Routing is not just a set of checkboxes in a portal; it is the fundamental logic that governs your infrastructure, and mastering it is a critical milestone in your Azure journey.