7.4 User-Defined Routes and Effective Routes

System routes versus UDRs

Azure automatically creates system routes for each subnet. Those routes let resources reach addresses in the VNet, peered VNets, the internet when allowed, and connected networks through gateways when configured. A user-defined route, or UDR, is an administrator-created route in a route table associated with a subnet. UDRs are used when the default path is not the required path.

Common UDR reasons include sending all outbound internet traffic to Azure Firewall, routing spoke-to-spoke traffic through a hub NVA, forcing traffic to on-premises, or overriding a learned route with a more specific path. UDRs are subnet-level controls. You do not attach a route table directly to a VM NIC in the usual AZ-104 workflow.

Route table example:

Longest prefix match

Azure route selection follows longest prefix match. The route with the most specific matching prefix wins. A route for 10.42.1.0/24 is more specific than 10.42.0.0/16, and both are more specific than 0.0.0.0/0. This matters when a default route sends internet traffic to a firewall but a specific route sends storage traffic, partner traffic, or another spoke prefix somewhere else.

Example:

Destination: 10.42.1.25
Routes:
  0.0.0.0/0 -> firewall
  10.42.0.0/16 -> peering
  10.42.1.0/24 -> virtual appliance 10.0.1.4
Selected route: 10.42.1.0/24 -> virtual appliance

If a question says one subnet can reach a destination but another cannot, compare their route table associations and effective routes. Subnets in the same VNet can have different route tables. A single wrong association can make only one tier fail.

Next hop types

Recognize the next hop types by scenario. Virtual appliance is used for Azure Firewall or an NVA and requires a next hop private IP. Virtual network gateway sends traffic to a VPN or ExpressRoute gateway. Internet sends traffic to the internet path. Virtual network keeps traffic inside the VNet. None drops matching traffic.

A route to None is a deliberate blackhole. It can be useful for blocking a prefix, but on the exam it may appear as the reason a connection fails even though an NSG appears open. Security rules allow or deny after routing has a path; if the selected route is None, the packet is dropped by routing.

Effective routes and next hop tools

Effective routes are the administrator's evidence. They combine system routes, user-defined routes, propagated routes, and peering routes for a NIC. Portal path: Network interface > Effective routes. You can also reach related views from the VM networking blade.

Network Watcher next hop asks Azure what next hop would be used from a source VM to a destination IP. This is especially useful when you suspect forced tunneling, gateway propagation, or an unexpected UDR. It answers the routing question before you spend time editing NSGs.

CLI examples:

az network nic show-effective-route-table \
  --resource-group rg-network \
  --name nic-web-01 \
  --output table

az network watcher show-next-hop \
  --resource-group rg-network \
  --vm vm-web-01 \
  --source-ip 10.41.1.4 \
  --dest-ip 10.42.1.10

Forced tunneling and hub firewall routing

Forced tunneling sends broad traffic, often 0.0.0.0/0, to a firewall, NVA, or gateway instead of the Azure internet path. In a hub-and-spoke design, workload subnets in spokes may have a UDR that points default traffic to Azure Firewall in the hub. The firewall then applies policy and sends allowed traffic onward.

Diagram:

spoke VM 10.41.1.4
   |
UDR 0.0.0.0/0 -> 10.0.1.4
   |
hub Azure Firewall 10.0.1.4
   |
internet or on-premises depending on policy and routes

This design needs four things: the UDR on the source subnet, peering that permits the path, firewall policy that allows the flow, and return routing that brings replies back through a valid path. If any one is missing, the route table might look correct but the connection still fails.

Route propagation

When a virtual network gateway exists, routes can be propagated to subnets. Route table settings can disable BGP route propagation. In AZ-104 scenarios, a subnet may fail to reach on-premises because gateway-propagated routes are disabled or because a UDR sends traffic elsewhere. Conversely, a subnet may unexpectedly send traffic to on-premises because propagated routes exist and are more specific than a default route.

When troubleshooting hybrid traffic, compare the on-premises prefix route, default route, and any more specific UDR. Also confirm the on-premises network has a return route to the Azure prefix. Azure routing can be correct in one direction while the remote router drops the return path.

Routing workflow for the exam

Use this sequence under time pressure:

1. Identify source subnet, destination IP, and port.
2. Check whether the destination IP is private, public, peered, or on-premises.
3. Inspect effective routes on the source NIC.
4. Run next hop if available.
5. Confirm UDR association on the source subnet.
6. Check peering, gateway propagation, and NVA IP forwarding if a virtual appliance is involved.
7. Then inspect NSGs, firewall policy, and guest firewall.

Scenario traps

Do not solve every connectivity failure with an NSG rule. If routing sends the packet to None, a firewall, or the wrong gateway, an allow rule will not help. Do not add a default route to a firewall without ensuring the firewall can reach Azure platform dependencies or required update endpoints. Do not forget that an NVA must be configured to forward traffic, and its NIC settings and guest OS must support forwarding.

A classic case says a VM can reach another VM by private IP until a route table is associated with the subnet. That points to a UDR problem. Another says internet access stopped after a 0.0.0.0/0 route was added to a firewall. That points to firewall policy, firewall public IP, SNAT, or return path, not a missing public IP on every VM.