Azure VNet Peering, UDR and Gateway Transit

Azure networking problems are usually routing problems. Peering connects two virtual networks privately, user-defined routes (UDRs) decide which next hop an address prefix takes, and gateway transit lets spokes borrow the hub's VPN or ExpressRoute gateway instead of building their own. Get those three interactions wrong and you get the classic symptom: peering shows Connected, but traffic between spokes or to on-premises never arrives. This guide explains the rules Azure actually applies.

Peering basics and what it does not do

Peering links two VNets (across Regions as well) and requires association in both directions - a half-configured peering stays in Initiated state and passes no traffic. Peered VNets do not need overlapping address space, and the route for the peering is created automatically with the Virtual network peering next hop type. Address space changes on either side require a peering resync, another frequent cause of "it worked last week".

UDRs: the next hop types that matter

• Virtual network gateway - send traffic to the VNet's VPN gateway. Supported when the gateway is a VPN gateway; with ExpressRoute the gateway is chosen by the platform, and a UDR pointing at VirtualNetworkGateway behaves accordingly.
• Virtual appliance - for an NVA (firewall, SD-WAN edge, load balancer), optionally with a private IP so the appliance receives a single encapsulated hop.
• Internet / None - override defaults. None is how you black-hole a prefix deliberately.

You cannot specify Virtual network peering or a service endpoint as a UDR next hop. Those route types only appear when you actually configure a peering or service endpoint - which is why "route to a peered VNet via UDR" designs fail.

Gateway transit: spoke borrowing the hub gateway

# hub side peering
az network vnet peering create -g rg-hub -n hub-to-spoke1   --vnet-name vnet-hub --remote-vnet vnet-spoke1   --allow-vnet-access --allow-gateway-transit

# spoke side peering (uses the hub gateway)
az network vnet peering create -g rg-spoke1 -n spoke1-to-hub   --vnet-name vnet-spoke1 --remote-vnet vnet-hub   --allow-vnet-access --use-remote-gateways

Gateway transit is enabled on the hub (the side owning the gateway) and consumed on the spoke. Spokes learn on-premises prefixes through the hub's gateway, and if a UDR exists in the spoke overriding that prefix, the UDR wins - the usual reason a spoke loses access to on-premises after a routing change.

Spoke-to-spoke patterns

1. Through the hub NVA - each spoke has a route table with 0.0.0.0/0 or the other spokes' prefixes pointing at the NVA's private IP, and the NVA peers with the spoke VNets directly.
2. Through the hub gateway - only sensible for cross-premises traffic; using a VPN gateway to move traffic between spokes gives no bandwidth guarantee, since that device exists to encrypt across sites.
3. Direct peering - when traffic volume justifies it, mesh the spokes and skip the NVA entirely.

Verify before you blame the peering

• az network nic show-effective-route-table -g rg-spoke1 -n nic-app1 -o table shows which route actually won, including UDR overrides and the peering hop type.
• Network Watcher > Next hop: test a destination address from a specific NIC and confirm where Azure intends to send it.
• Network Watcher > Connection troubleshoot between two VMs, which also surfaces NSG blocks in the same result.
• Gateway side: if the session is eBGP over ExpressRoute, verify the advertised prefixes as described in Azure ExpressRoute: Circuits, Private Peering and BGP.

One caution for network engineers: the Azure fabric will happily accept a UDR design that black-holes traffic, because NSGs and routing are evaluated independently. Validate both at once. The same discipline applies in hybrid SD-WAN overlays - see Cisco Catalyst SD-WAN Architecture: Planes and Components - and when troubleshooting host-side routes on Linux VMs, Linux Network Namespaces and VRFs: A Hands-On Lab is the equivalent toolset.

原文链接：https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview