System Routes and Custom Routes

Azure Routing: Mastering System and Custom Routes

Introduction: The Backbone of Azure Networking

In the world of cloud computing, infrastructure is only as good as the communication paths between its components. When you deploy a virtual machine, a database, or a load balancer in Microsoft Azure, those resources need a way to find each other. This is the fundamental purpose of routing. Routing is the process of selecting paths in a network along which to send network traffic. Without clear routing rules, your cloud environment would be a collection of isolated silos, unable to perform the tasks they were designed for.

Azure handles routing automatically through a sophisticated system of default routes, but as your architecture grows in complexity, you will inevitably need to exert more control. Understanding the difference between system-defined routes and user-defined routes is the difference between a network that "just works" and a network that is secure, optimized, and prepared for enterprise-grade traffic patterns. This lesson will guide you through the mechanics of how Azure manages traffic flow, how to manipulate that flow, and how to avoid the common pitfalls that often lead to connectivity issues.

By the end of this module, you will understand how packets travel within a Virtual Network (VNet), how to override default behaviors to inspect traffic through firewalls, and how to ensure your network remains performant and secure. Whether you are preparing for an architect certification or managing a production environment, mastering these routing principles is non-negotiable.

Understanding System Routes

When you create a Virtual Network in Azure, the platform automatically creates a set of system routes. These routes are pre-populated into every subnet within that virtual network. You do not need to configure them; they are the "default intelligence" that Azure provides to ensure that resources within your environment can talk to each other and to the internet.

How System Routes Work

System routes are applied to every network interface (NIC) attached to a virtual machine. These routes dictate how traffic is directed based on the destination IP address. Azure maintains a routing table for every subnet, and these system routes are always present. You cannot delete system routes, but you can override them with custom routes.

The primary system routes include:

• VNet Local: Traffic destined for an address within the same virtual network is routed directly between the resources.
• On-Premises: If you have a VPN gateway or ExpressRoute connected to your VNet, Azure automatically adds routes to reach your local network addresses.
• Internet: Traffic destined for public IP addresses outside of your VNet is routed to the internet gateway.
• Service Tags: Azure provides routes to internal Azure services (like Storage or SQL) based on service tags, which represent groups of IP addresses for specific services.

Callout: System Routes vs. Custom Routes System routes are managed entirely by the Azure platform and are updated dynamically as you add or remove resources from your network. Custom routes (User-Defined Routes or UDRs) are manually created by administrators to override these system defaults. While system routes provide the baseline connectivity, custom routes provide the control necessary for security appliances, hub-and-spoke topologies, and complex traffic engineering.

Why System Routes Matter

Without these default routes, you would have to manually define the path for every single packet. Imagine having to tell a web server exactly how to reach the Azure SQL database it relies on. System routes automate this "neighbor discovery," ensuring that as soon as you add a new subnet or peer two VNets together, the routing tables update themselves to reflect the new topology.

Implementing Custom Routes (User-Defined Routes)

While system routes are excellent for simple environments, they often fall short in production scenarios where security and traffic inspection are priorities. This is where User-Defined Routes (UDRs) come into play. A UDR allows you to create a "Route Table" resource in Azure and associate it with one or more subnets.

The Anatomy of a Route Table

A route table consists of one or more routes. Each route defines:

1. Address Prefix: The destination IP range (CIDR block) that this route applies to.
2. Next Hop Type: The method by which the packet should be forwarded (e.g., Virtual Appliance, Virtual Network Gateway, Internet, or None).
3. Next Hop IP Address: The specific IP address of the device that should receive the traffic if the hop type is a Virtual Appliance.

Practical Example: The "Hub and Spoke" Inspection Pattern

A common enterprise requirement is to force all traffic from a "spoke" VNet through a centralized "hub" VNet where a Network Virtual Appliance (NVA)—such as an Azure Firewall or a third-party firewall—resides.

Step-by-Step Implementation:

1. Create the Route Table: Use the Azure Portal or Azure CLI to create a new Route Table resource.
2. Define the Route: Create a route named ToFirewall. Set the address prefix to 0.0.0.0/0 (the internet). Set the next hop type to Virtual Appliance and provide the private IP address of your firewall.
3. Associate the Table: Associate this table with the subnet in your spoke VNet.

Warning: The 0.0.0.0/0 Trap Creating a route for 0.0.0.0/0 (the default route) will override the default internet route provided by Azure. If you do this without having a valid firewall or gateway ready to receive that traffic, you will immediately lose internet connectivity for all resources in that subnet. Always test your UDRs in a non-production subnet first.

Code Example: Creating a Route Table via Azure CLI

The Azure CLI is a powerful tool for managing routing, especially when you need to script the deployment of complex network topologies.

# Create a resource group
az group create --name MyRoutingRG --location eastus

# Create the route table
az network route-table create \
  --resource-group MyRoutingRG \
  --name MySpokeRouteTable

# Create a route that directs traffic to a virtual appliance
az network route-table route create \
  --resource-group MyRoutingRG \
  --route-table-name MySpokeRouteTable \
  --name ToNVA \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.5

# Associate the route table with a specific subnet
az network vnet subnet update \
  --resource-group MyRoutingRG \
  --vnet-name MySpokeVNet \
  --name SpokeSubnet \
  --route-table MySpokeRouteTable

In this example, we define a route that forces all traffic destined for the internet to hit the appliance at 10.0.1.5. By associating this table with the SpokeSubnet, we effectively "hijack" the default internet path and redirect it through our security layer.

Comparing Routing Options

To make the right choice, it is helpful to visualize how different next-hop types interact with your network.

Note: The "None" next-hop type is an often overlooked but highly effective security feature. If you have a subnet that should never communicate with the internet, you can create a UDR with 0.0.0.0/0 and set the next hop to None. This creates a "blackhole" that ensures no traffic can leak out, regardless of what other configurations are in place.

Best Practices for Azure Routing

Managing routes in a large Azure environment requires discipline. If you allow "configuration drift"—where routes are added manually and inconsistently—you will eventually face a troubleshooting nightmare.

1. Centralize Your Route Tables

Do not define routes on a per-subnet basis if you can avoid it. Instead, use a centralized naming convention and grouping strategy. If you are using Infrastructure as Code (IaC) tools like Terraform or Bicep, define your route tables in a shared module. This ensures that every subnet in your organization follows the same routing logic.

2. Use "Next Hop" IP Addresses Carefully

When using a Virtual Appliance as a next hop, ensure that the appliance is highly available. If the appliance goes down and you have a UDR pointing to it, your traffic will be dropped. Consider using Azure Load Balancer in front of your NVAs to ensure that traffic is always directed to a healthy instance.

3. Document Your Routing Logic

Routing tables are invisible to the casual observer. A developer might look at a VM and wonder why it cannot reach the internet. If you have a UDR in place, it is not immediately obvious from the VM's interface settings. Maintain documentation or use tags on your route table resources to explain why a specific route exists.

4. Leverage Azure Network Watcher

Azure provides a tool called "Next Hop" within Network Watcher. This tool allows you to input a source VM and a destination IP, and it will tell you exactly which route is being applied to that packet. This is invaluable for debugging. If a packet is being dropped or sent to the wrong place, Network Watcher will show you the specific route table and rule responsible.

Common Pitfalls and Troubleshooting

Even experienced engineers run into issues with Azure routing. Here are the most common scenarios and how to resolve them.

Pitfall 1: Asymmetric Routing

Asymmetric routing occurs when traffic leaves a resource through one path but returns through another. For example, if a request goes from a VM to a firewall, then to the internet, but the response comes directly from the internet to the VM (bypassing the firewall), the firewall will likely drop the connection because it never saw the initial request.

• The Fix: Ensure that your return traffic is also routed through the same appliance. This often requires setting up UDRs on the gateway subnets or the subnets receiving the response.

Pitfall 2: Overlapping Prefixes

If you have multiple routes that could apply to the same destination, Azure uses the "Longest Prefix Match" rule. If you have a route for 10.0.0.0/16 and another for 10.0.1.0/24, traffic to 10.0.1.5 will follow the /24 route because it is more specific.

• The Fix: Always be mindful of your CIDR ranges. If you are troubleshooting, check if a more specific route is accidentally overriding your intended general route.

Pitfall 3: Default Route Conflict

Sometimes, you might add a UDR to force traffic to an NVA, but the traffic still seems to be going directly to the internet. This often happens because the VM has a Public IP assigned to it.

• The Fix: In Azure, a Public IP assigned directly to a NIC takes precedence over any UDR for internet-bound traffic. If you want to force internet traffic through a firewall, you must remove the Public IP from the VM or use a NAT Gateway combined with specific routing configurations.

Callout: The "Public IP" Priority It is a common misconception that a UDR can override the path taken by a VM that has a Public IP address assigned. If a VM has a Public IP, its outbound internet traffic will bypass UDRs and go straight to the internet. To ensure full control, remove Public IPs from your VMs and route all egress traffic through a centralized firewall or NAT Gateway.

Advanced Routing Concepts: BGP and Propagation

For large enterprise networks, manual UDR management becomes unsustainable. This is where Border Gateway Protocol (BGP) becomes relevant. When you connect your on-premises network to Azure via ExpressRoute or a VPN Gateway, BGP allows the two networks to "talk" to each other and exchange routing information automatically.

Route Propagation

When BGP is enabled, your virtual network gateway learns routes from your on-premises environment and automatically injects them into your VNet's route tables. This is known as "Gateway Route Propagation."

You can disable this propagation on a per-subnet basis if you want to prevent certain subnets from learning about on-premises routes. This is useful for creating isolated subnets that should only communicate with other Azure resources and never with the local corporate network.

BGP Best Practices:

• Keep it simple: Avoid complex BGP path manipulation unless absolutely necessary.
• Monitor your peers: Use Azure metrics to track the health of your BGP sessions.
• Route Summarization: Where possible, advertise summarized routes (shorter prefixes) to keep the routing tables on your Azure gateways clean and efficient.

Infrastructure as Code (IaC) and Routing

In modern DevOps environments, you should never create a route table manually in the portal. Doing so leads to "snowflake" configurations that are impossible to replicate. Instead, use templates (Bicep or ARM) or Terraform to define your networking.

Example: Terraform Snippet for a Route

Using Terraform allows you to treat your routing as part of your application's lifecycle.

resource "azurerm_route_table" "example" {
  name                = "example-route-table"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name

  route {
    name           = "to-firewall"
    address_prefix = "0.0.0.0/0"
    next_hop_type  = "VirtualAppliance"
    next_hop_in_ip_address = "10.0.1.5"
  }
}

By defining this in code, you gain version control, peer review, and the ability to roll back changes if a new routing rule breaks connectivity. This is the industry standard for managing cloud networks at scale.

Summary and Key Takeaways

Routing is the silent engine of your Azure infrastructure. It is the framework that dictates how data moves, how security is enforced, and how different parts of your environment interact. By mastering the distinction between system routes and user-defined routes, you move from being a user of the cloud to an architect of the cloud.

Key Takeaways:

1. System Routes are Automatic: Azure provides default routing intelligence that handles standard connectivity between subnets, VNets, and the internet. You do not need to manage these, but you must understand them to troubleshoot effectively.
2. UDRs Provide Control: When default behavior is insufficient—such as when you need to force traffic through a firewall—User-Defined Routes (UDRs) are the mechanism to override system defaults.
3. The "Longest Prefix Match" Rule: Azure always prioritizes the most specific route. If you have overlapping ranges, the smallest CIDR block wins.
4. Public IP Precedence: Remember that a Public IP assigned directly to a virtual machine overrides UDRs for internet-bound traffic. If you need to force traffic through a firewall, ensure your VMs do not have direct public internet access.
5. Use Network Watcher: Never guess why a packet is failing. Use the "Next Hop" tool in Azure Network Watcher to see exactly how Azure is interpreting your routing tables for a given destination.
6. Infrastructure as Code is Mandatory: Manual routing changes lead to configuration drift and outages. Always define your route tables in Bicep, ARM, or Terraform to ensure consistency and auditability.
7. Prioritize Security: Use the "None" next-hop type to blackhole traffic for high-security subnets that should never communicate with the outside world.

As you continue your journey in Azure networking, remember that the best network is often the simplest one. Only add complexity when the business requirements—such as security auditing or hybrid connectivity—demand it. By following the principles outlined in this lesson, you will be able to build network architectures that are reliable, secure, and easy to maintain.

Frequently Asked Questions (FAQ)

Q: Can I delete a system route? A: No. System routes are immutable. You can only override them by creating a more specific user-defined route.

Q: What happens if I have multiple route tables associated with the same subnet? A: You cannot associate multiple route tables with a single subnet. You must consolidate all your custom routes into a single route table resource and associate that one table with the subnet.

Q: How do I know if my route table is actually working? A: Use the "Next Hop" feature in Azure Network Watcher. It will show you exactly which route table and route are being applied to a test packet sent from a specific source.

Q: Is there a limit to how many routes I can have in a route table? A: Yes, there are limits on the number of routes per route table (typically 400). If you find yourself hitting this limit, you likely have an overly complex network design and should consider consolidating your address prefixes.

Q: Does a UDR affect traffic between subnets in the same VNet? A: Yes, it can. If you create a UDR for an internal destination, it will override the default "VNet Local" route, potentially forcing internal traffic through a virtual appliance or other hop. Be cautious when defining routes for internal IP ranges.

Q: What is the benefit of using a NAT Gateway? A: A NAT Gateway provides a centralized, scalable way to handle outbound internet traffic. It allows you to use a static public IP for all your outbound traffic, which is often a requirement for whitelisting at third-party services, while keeping your VMs isolated from inbound internet traffic.

Final Thoughts for the Practitioner

The transition from a basic cloud setup to a professional-grade network architecture is marked by your comfort level with routing. When you can look at a network diagram and intuitively understand how a packet flows from a web server to a database, through a firewall, and back to the client, you have mastered the material.

Start small. Experiment with a UDR in a sandbox environment. Force some traffic through a dummy virtual appliance and observe the behavior using Network Watcher. Once you see the "Next Hop" change in your test, the concepts will click. Routing is not just about moving data; it is about defining the boundaries and the safety protocols of your digital ecosystem. Keep your configurations clean, your documentation updated, and your infrastructure defined in code. You are now equipped to manage the flow of traffic in any Azure environment you encounter.