This chapter covers User-Defined Routes (UDR) and route tables in Azure, a critical topic for the AZ-104 exam under Domain 4 (Networking), Objective 4.1. UDRs allow you to override Azure's default routing behavior, enabling custom network topologies such as forced tunneling, traffic inspection via Network Virtual Appliances (NVAs), and hub-and-spoke architectures. Approximately 10-15% of exam questions touch on routing, with a focus on route tables, next hop types, and effective routes. Mastery of UDRs is essential for designing secure and efficient Azure networks.
Jump to a section
Imagine Azure's default routing as a GPS navigation system in a delivery truck. The GPS knows the fastest roads (Azure's default system routes) and automatically routes the truck from the warehouse (source subnet) to the customer (destination). Now, you need the truck to go through a security checkpoint for inspection before reaching certain customers. You can't reprogram the entire GPS, but you can add a custom waypoint: 'Before delivering to any customer on Elm Street, first go to 123 Security Lane.' This is exactly what a User-Defined Route (UDR) does. It overrides the default next hop for specific traffic. In Azure, the route table is like a list of these custom waypoints. Each route has an address prefix (the destination, like 'Elm Street'), a next hop type (the inspection checkpoint, like a Network Virtual Appliance), and a priority. If multiple routes match, the most specific prefix wins—just as a GPS would prioritize a specific street address over a general city name. The truck's driver (the virtual network's routing engine) consults the route table at every intersection (each hop) and follows the most specific instruction. If no custom route matches, it falls back to the default GPS (system routes). This mechanism enables traffic inspection, forced tunneling, and hub-and-spoke topologies.
What is a User-Defined Route (UDR)?
A User-Defined Route (UDR) is a custom route you create in an Azure route table to override Azure's default system routes. Azure automatically creates system routes for each virtual network (VNet) subnet, enabling communication within the VNet, across peered VNets (via VNet peering or VPN gateways), and to the internet. When you need traffic to take a different path—for example, to flow through a firewall or an NVA for inspection—you associate a route table containing UDRs with the subnet.
How Azure Routing Works Internally
Azure's routing engine operates at the subnet level. Each subnet has an associated route table (either default system routes or a custom one). When a packet leaves a VM in a subnet, the host node checks the effective routes for that subnet. The route lookup uses a longest prefix match (LPM) algorithm: the most specific route (i.e., the route with the longest matching prefix) wins. If multiple routes have the same prefix length, the route with the lowest priority (system routes have priority 100, custom routes have priority 0) is used—custom routes always override system routes for the same prefix. If no match is found, the packet is dropped.
Key Components and Defaults
- Route Table: A logical container for UDRs. You create a route table and associate it with zero or more subnets. A subnet can have only one route table, but the same route table can be associated with multiple subnets. - Route: Contains: - Address Prefix: The destination CIDR (e.g., 10.0.1.0/24). You can also use a service tag as the prefix (preview) to route traffic to Azure services. - Next Hop Type: One of: - *Virtual appliance*: IP address of an NVA (e.g., firewall, load balancer). Must be a private IP reachable from the subnet. - *VNet peering*: Routes traffic to a peered VNet (system route; cannot be set in UDR). - *VNet gateway*: Routes traffic to a VPN/ExpressRoute gateway (system route). - *Internet*: Routes traffic to the internet (system route). - *None*: Drops traffic matching the prefix. - Next Hop IP Address: Required only for next hop type 'Virtual appliance'. - Priority: Not configurable in UDRs; custom routes always override system routes for the same prefix. However, you cannot delete or override the system route for 0.0.0.0/0 (default internet route) without adding a UDR for 0.0.0.0/0 with next hop 'Virtual appliance' or 'None'. - Propagation: By default, route tables do not propagate routes from on-premises via VPN/ExpressRoute. You can enable 'virtual network gateway route propagation' on a route table to add those routes. - Effective Routes: The resultant set of routes after combining system routes and UDRs. You can view effective routes for a VM, NIC, or subnet using Azure Portal, Azure CLI, or PowerShell.
Configuration and Verification Commands
Create a route table (Azure CLI):
az network route-table create --name MyRouteTable --resource-group MyRG --location eastusAdd a route:
az network route-table route create --name ToOnPrem --resource-group MyRG --route-table-name MyRouteTable --address-prefix 10.0.0.0/8 --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.100.4Associate route table with subnet:
az network vnet subnet update --name MySubnet --resource-group MyRG --vnet-name MyVNet --route-table MyRouteTableView effective routes for a NIC:
az network nic show-effective-route-table --name MyNic --resource-group MyRGInteraction with Related Technologies
VNet Peering: Peering adds system routes for the peer's address space. UDRs can override these routes, allowing you to route traffic from a spoke through a hub NVA before reaching the peer.
VPN/ExpressRoute: System routes for on-premises networks are added automatically when a gateway is connected. UDRs can override these routes, enabling forced tunneling (all internet traffic goes through on-premises).
Service Endpoints: Service endpoints create a direct route to Azure PaaS services. UDRs have lower priority than service endpoint routes for the same prefix; you cannot override a service endpoint route with a UDR.
Azure Firewall: A common NVA. You can set next hop to Azure Firewall's private IP (or use the AzureFirewallSubnet route table for forced tunneling).
Virtual WAN: In Virtual WAN, route tables are managed differently; UDRs are not supported in the same way, but you can use virtual hub routing.
Forced Tunneling Example
Forced tunneling ensures that all internet-bound traffic from a VM goes through an on-premises firewall. To achieve this, add a route with prefix 0.0.0.0/0 and next hop type 'Virtual appliance' pointing to your NVA's IP. Then, ensure the NVA routes traffic to the internet via an on-premises gateway (e.g., VPN). Without this UDR, the default system route for 0.0.0.0/0 sends internet traffic directly out of Azure's edge.
Limitations and Edge Cases
Next hop IP must be directly reachable: The next hop IP must be in the same VNet or a connected network via peering/gateway. You cannot point to an IP in a different region without additional routing.
UDRs do not affect traffic within the same subnet: Traffic between VMs in the same subnet uses the subnet's local broadcast; UDRs are not consulted.
UDRs are not applied to traffic from Azure services: For example, Azure Load Balancer health probes bypass UDRs.
Route limit: Each route table can have up to 400 routes (default). You can increase this via support request.
Propagation of on-prem routes: If you enable gateway route propagation, the route table will include routes learned from on-premises via BGP. These routes have a priority of 100 (same as system routes), so UDRs still override them for the same prefix.
Verification and Troubleshooting
Use the Next Hop diagnostic in Azure Network Watcher to test the effective route for a specific source and destination IP. This tool shows the next hop type and IP, helping you validate UDR configuration.
az network watcher show-next-hop --vm myVM --resource-group MyRG --source-ip 10.0.0.4 --dest-ip 10.1.0.10Common issues:
Asymmetric routing: If traffic takes one path but return traffic takes another, firewalls may drop packets. Ensure UDRs are symmetrical or use stateful inspection.
Missing route for return traffic: If you route outbound traffic through an NVA, ensure the NVA has a route back to the source, or use SNAT.
Overlapping prefixes: A more specific UDR can unintentionally override a broader system route, causing traffic to be dropped (if next hop is 'None') or misrouted.
Identify Routing Requirements
Determine which subnets need custom routing. Common scenarios: forced tunneling (all internet traffic through on-premises), traffic inspection (e.g., via a firewall), or hub-and-spoke topology where spoke traffic must pass through a hub NVA. Document the destination prefixes (on-premises ranges, internet, specific services) and the desired next hop (e.g., NVA private IP). Consider that UDRs apply only to outbound traffic from the subnet; inbound traffic is controlled by the source's routing.
Create a Route Table
In the Azure portal, CLI, or PowerShell, create a route table in the same region as the VNet. Use a descriptive name (e.g., 'Spoke1-RouteTable'). Do not associate it with any subnet yet. By default, gateway route propagation is disabled; enable it only if you want the route table to include routes learned from on-premises via VPN/ExpressRoute. This step creates an empty container.
Add User-Defined Routes
Add routes to the route table. Each route requires an address prefix (CIDR) and a next hop type. For an NVA, set next hop type to 'Virtual appliance' and provide the private IP of the NVA. For forced tunneling, add a route with prefix 0.0.0.0/0. For dropping traffic, use 'None'. You can add multiple routes. The order does not matter because the longest prefix match determines which route is used. Verify that the next hop IP is reachable from the subnet.
Associate Route Table with Subnet
Associate the route table with one or more subnets by updating the subnet's properties. A subnet can have only one route table. Once associated, all VMs in that subnet will use the UDRs for outbound traffic. The association takes effect immediately; no restart is required. You can disassociate by setting the route table to 'None'.
Verify Effective Routes
After association, verify the effective routes for a VM or NIC in the subnet. Use Azure Portal (Effective Routes tab), Azure CLI (`az network nic show-effective-route-table`), or PowerShell (`Get-AzEffectiveRouteTable`). Confirm that the custom routes appear and have the expected next hop. Use Network Watcher's Next Hop diagnostic to test a specific traffic flow. Troubleshoot if the expected route is missing or if traffic is not following the intended path.
Enterprise Scenario 1: Forced Tunneling in a Hybrid Network
A financial services company uses Azure for IaaS workloads but must enforce that all internet-bound traffic goes through their on-premises firewall for compliance. They have a hub-and-spoke topology with a VPN gateway in the hub connecting to on-premises. In each spoke subnet, they associate a route table with a UDR for 0.0.0.0/0 pointing to the hub's NVA (e.g., Azure Firewall). The NVA then routes traffic to the on-premises firewall via the VPN. At scale, they manage dozens of spoke VNets each with the same route table. A common pitfall: forgetting to add a route for the on-premises prefix (e.g., 10.0.0.0/8) to the route table, causing traffic to on-premises to be routed through the NVA instead of directly, leading to latency and potential asymmetric routing. They use Azure Policy to enforce that all subnets have a route table with the 0.0.0.0/0 UDR.
Scenario 2: Traffic Inspection via NVA in Hub
An e-commerce company uses a third-party NVA (e.g., Palo Alto Networks) in a hub VNet to inspect all traffic between spokes and to the internet. Each spoke subnet has a UDR for the hub's address space (10.0.0.0/16) pointing to the NVA's IP (10.0.0.4). However, they also need to route traffic between two spoke VNets through the hub. They add a UDR for each spoke's address prefix (e.g., 10.1.0.0/16 and 10.2.0.0/16) pointing to the NVA. Performance is a concern: the NVA must handle all inter-spoke traffic, so they scale out the NVA and use Azure Load Balancer with floating IP. A misconfiguration that often occurs: they forget to add a route for the hub's own subnets (e.g., management subnet) which causes the NVA to lose connectivity.
Scenario 3: Internet Egress via Azure Firewall
A SaaS provider uses Azure Firewall to inspect and filter outbound internet traffic from their application subnets. They create a route table with a default route (0.0.0.0/0) pointing to Azure Firewall's private IP (which is in the AzureFirewallSubnet). They associate this route table with all application subnets. At scale, they have multiple Azure Firewall instances in different regions, each with its own route table. They use Azure Firewall Manager to centralize policy. A common issue: when they deploy a new subnet, they forget to associate the route table, causing VMs to have direct internet access (bypassing the firewall). They use Azure Policy to auto-assign the route table.
What AZ-104 Tests on UDRs
AZ-104 exam objectives under Domain 4.1 include: configuring and managing route tables, understanding system routes vs. UDRs, next hop types, forced tunneling, and troubleshooting routing with effective routes and Network Watcher. Specific objective: 'Configure and manage virtual networking, including custom routes.' Expect 3-5 questions on routing.
Common Wrong Answers and Why
'UDRs can override VNet peering routes' — This is partially true but misleading. UDRs can override the system route for a peered VNet's address space, but you cannot delete the peering route itself. The UDR takes precedence because it has higher priority (lower numeric value) for the same prefix. However, if the peering is not established, the UDR has no effect. Candidates often think UDRs can bypass peering requirements.
'Next hop type Virtual appliance requires a public IP' — Wrong. The next hop IP must be a private IP reachable from the subnet. Public IPs are not supported because Azure routes private traffic internally.
'You can associate a route table with a VNet' — Wrong. Route tables are associated with subnets, not VNets. This is a classic trap. You must associate at the subnet level.
'UDRs affect traffic within the same subnet' — False. UDRs only affect traffic leaving the subnet. Intra-subnet traffic uses local broadcast and is not routed.
Specific Numbers and Terms
400 routes per route table (default limit).
Priority: System routes have priority 100, custom routes have priority 0 (effective). But the exam focuses on longest prefix match, not priority numbers.
Next hop types: Virtual appliance, VNet peering, VNet gateway, Internet, None. (VNet peering and VNet gateway are system-only; you cannot create UDRs with these types.)
Forced tunneling: A UDR with 0.0.0.0/0 to Virtual appliance is the key.
Effective routes: Use Azure CLI az network nic show-effective-route-table or Portal.
Edge Cases and Exceptions
Service endpoint routes: Cannot be overridden by UDRs. If a subnet has a service endpoint for Microsoft.Storage, traffic to Storage uses the service endpoint route regardless of UDRs.
Azure DNS: Traffic to Azure DNS (168.63.129.16) is not affected by UDRs; it bypasses the route table.
Azure Load Balancer health probes: Source IP is 168.63.129.16 and bypasses UDRs.
Gateway transit: In hub-spoke with gateway transit, the spoke's route table must not have a UDR for the hub's address space that points to the NVA if you want direct connectivity; otherwise, traffic will hairpin.
How to Eliminate Wrong Answers
Read the question carefully: Is the route table associated with the correct subnet? Does the next hop IP exist and is it reachable? Does the prefix match exactly? Remember that UDRs only affect outbound traffic. If the question involves inbound traffic, UDRs are not the answer. Use effective routes to verify.
Route tables are associated with subnets, not VNets.
UDRs override system routes based on longest prefix match.
Next hop types: Virtual appliance (requires private IP), None (drops traffic).
Forced tunneling: add UDR with 0.0.0.0/0 to NVA.
UDRs do not affect intra-subnet traffic, Azure DNS, or LB health probes.
Service endpoint routes cannot be overridden by UDRs.
Maximum 400 routes per route table (default).
Use Network Watcher Next Hop to validate routing.
These come up on the exam all the time. Here's how to tell them apart.
User-Defined Routes (UDRs)
Static routes defined manually in route tables.
Applied at subnet level via route table association.
Supports next hop types: Virtual appliance, None, etc.
Cannot dynamically learn routes from on-premises (unless gateway propagation enabled).
Used for forced tunneling, traffic inspection, and custom topologies.
Azure Route Server
Dynamic BGP route exchange with NVAs and on-premises.
Injects routes into all subnets in a VNet (not per subnet).
Routes are learned via BGP from NVAs or on-premises routers.
Enables dynamic routing without static UDRs; reduces management overhead.
Used for NVA high availability and dynamic routing in hub-and-spoke.
Mistake
UDRs can be applied to virtual networks directly.
Correct
Route tables are associated with subnets, not entire VNets. You must associate the route table with each subnet individually.
Mistake
A UDR with next hop 'None' blocks all traffic matching the prefix.
Correct
It drops traffic that matches the prefix, but it does not block traffic that does not match. Also, traffic to Azure DNS, load balancer health probes, etc., bypasses UDRs.
Mistake
UDRs can override service endpoint routes.
Correct
Service endpoint routes have higher priority than UDRs. If a subnet has a service endpoint for a service, UDRs for that service's prefix are ignored.
Mistake
You can use a public IP as the next hop for a Virtual appliance.
Correct
Next hop IP must be a private IP reachable from the subnet. Public IPs are not supported because Azure routes private traffic internally.
Mistake
UDRs affect inbound traffic to a subnet.
Correct
UDRs only affect outbound traffic from the subnet. Inbound traffic is controlled by the source's routing.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
System routes are automatically created by Azure for each subnet, enabling default communication within the VNet, across peered VNets, to the internet, and via VPN/ExpressRoute gateways. User-defined routes (UDRs) are custom routes you create in a route table to override system routes. UDRs have higher priority than system routes for the same prefix, allowing you to redirect traffic to a network virtual appliance or drop it. You cannot delete system routes, but you can override them with UDRs.
Yes, a single route table can be associated with multiple subnets, even across different VNets (within the same region). This is useful for applying consistent routing policies (e.g., forced tunneling) to many subnets. However, each subnet can have only one route table associated at a time. To change the route table, you must disassociate the current one and associate the new one.
Setting next hop type to 'None' causes Azure to drop any traffic that matches the route's address prefix. This is useful for intentionally blocking traffic to a specific destination, such as a misconfigured on-premises network range. However, note that Azure DNS (168.63.129.16) and load balancer health probes bypass UDRs, so they will still reach their destinations. Also, traffic to the VNet's own subnets is not affected because intra-subnet traffic does not use route tables.
To force all internet-bound traffic from a subnet to go through an on-premises firewall, create a UDR with address prefix 0.0.0.0/0 and next hop type 'Virtual appliance', pointing to the private IP of your firewall (which could be in Azure or on-premises via a VPN). Associate the route table with the subnet. Ensure the firewall has a route back to the subnet and can forward traffic to the internet. This is called forced tunneling. Also, ensure that the firewall's subnet does not have a similar UDR that would cause a loop.
Common reasons: (1) The route table is not associated with the correct subnet. (2) The next hop IP is not reachable (e.g., the NVA is in a different VNet without peering, or the IP is incorrect). (3) A more specific system route exists (e.g., a service endpoint route) that overrides your UDR. (4) The traffic is intra-subnet, so UDRs are not consulted. (5) The UDR is for inbound traffic, but UDRs only affect outbound. Use Network Watcher's Next Hop diagnostic to verify the effective route for a specific flow.
Yes, you can use a UDR to route traffic to an on-premises network by specifying the on-premises prefix and next hop type 'Virtual appliance' (if you want traffic to go through an NVA) or by relying on system routes from the gateway. However, if you want traffic to go directly to on-premises, you typically do not need a UDR because the VPN/ExpressRoute gateway automatically adds system routes for the on-premises prefixes. UDRs are used when you want to force traffic through an intermediate hop (e.g., an NVA) before reaching on-premises.
Gateway route propagation is a setting on a route table that, when enabled, automatically adds routes learned from on-premises via BGP (through a VPN gateway or ExpressRoute) to the route table. This is useful when you want subnets to have routes to on-premises without manually adding them. However, if you enable propagation, the propagated routes have a priority of 100 (same as system routes), so UDRs with the same prefix still take precedence. Enable propagation only if you want dynamic on-premises routes; otherwise, keep it disabled to avoid unintended routes.
You've just covered User-Defined Routes (UDR) and Route Tables — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?