User-Defined Routes (UDR)

Scope: Microsoft Learn / Azure Architecture Centerの一次資料を基準に、設計と運用で判断が必要な点をpacket path中心に整理。SKU、region、limitsは変更されるため、実装時はOfficial sourcesのcurrent documentationを再確認してください。

User-Defined Routes (UDR)を理解するための前提

route tableは0個以上のsubnetへassociateできるが、1 subnetにassociateできるroute tableは0または1。 UDRはsystem routeと合成され、同じprefix classなら一般にUDRがBGP/systemより優先する。

route selectionはまずlongest prefix match。0.0.0.0/0 UDRがあっても、よりspecific routeが存在すればそちらが選ばれる。 Virtual appliance next hopには直接到達できるprivate IP等を指定し、NVA NIC/OSのforwardingが必要。

GatewaySubnetへ不適切な0/0 UDRを付けるとVPN gatewayが正常動作しない可能性がある。 UDRの正しさはroute table定義ではなく代表NICのeffective routes + destination-specific next hop + actual flowで受け入れる。

通信や判断の流れを追う

SourceEffective routeNext hopDestinationReturn path

Control plane と data plane

Control planePortal / ARM / CLIで定義されたresource、association、route advertisement、peering flagなど。設定がSucceededでもpacket到達を保証しない。

Data plane実際のsource/destination/5-tupleが選ぶroute、NAT、security device、return path。Effective state、Next hop、logs、packet capture、application testで証明する。

仕組み

route table association後、Azure SDNはUDRをそのsubnetのeffective route setへ合成する。

packetのdestinationに対しLPMでcandidateが絞られ、同一prefixのsource priority等でselected routeが決まる。

Virtual appliance経由ではAzureがNVA private IPへpacketを送るだけで、その先のforwarding/NAT/securityはNVA responsibility。

stateful NVAを使う場合、source subnetだけでなくdestination/return sideのrouteも対で設計する。

Packet path

routing問題は「どのresourceがあるか」ではなく、packetが各hopで何を選ぶかを順に追う。

source subnetのeffective route setを取得。
destination prefixにLPM。
同一prefixのroute source priorityを評価。
selected next hopへ送信。
NVA/gateway/Internetで処理後、return sideも独立にroute selection。

設計判断

判断点	推奨	理由
Prefix specificity	必要最小のprefixで意図を表し、0/0乱用を避ける。	blast radiusを限定。
Next hop	NVA health/HAとdirect reachabilityを確認。	UDRはappliance availabilityを自動保証しない。
Propagation	BGP route propagation disableの理由を明示。	hybrid prefixを意図せず消さない。
Review	route table diff + effective route diff + traffic matrixをセット。	control planeとdata planeを結びつける。

確認手順

Azure Portal

Route tables → Routes / Subnets / Propagate gateway routesを確認。
対象NICのEffective routesでUDRがActiveか確認。
Network Watcher Next hopで代表destinationのselected next hopを確認。

Verification discipline

subscription / resource group / resource IDを記録する。
同じsource・destinationでbefore/afterを比較する。
read-only evidenceを保存してから変更する。
control-plane successとapplication successを別々に判定する。

Azure CLI — read-only first

az network route-table show -g <rg> -n <rt> -o jsonc
az network route-table route list -g <rg> --route-table-name <rt> -o table
az network nic show-effective-route-table -g <rg> -n <nic> -o table

PowerShell — read-only first

Get-AzRouteTable -ResourceGroupName <rg> -Name <rt>

障害切り分け

症状	疑う点	証拠	次の確認
route追加したのに使われない	more-specific route/preferred route	effective routes + Next hop	LPM/sourceを確認
NVAまで届くが先へ行かない	NVA forwarding/policy	NVA capture/log	IP forwarding/OS route/policy確認
returnだけ失敗	asymmetric route	両側effective route/capture	return UDR/BGP/SNATを修正
Gateway障害	GatewaySubnetの0/0/propagation設定	GatewaySubnet route table	Microsoft guidanceに反するUDRを除去

変更時の確認と rollback

変更前にroute table JSONと代表NIC effective routeを保存。
routeは1本ずつimpact prefix/flowsを記載。
変更後はNetwork Watcher Next hopとnew application connectionを同じdestinationで再実行。
rollback後にroute convergenceとNVA state/sessionを確認。

User-Defined Routes (UDR)