Effective Routes

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

Effective Routesを理解するための前提

effective routesは単一route tableではなく、そのNIC/subnetに作用する複数route sourceを統合したview。 Address prefix、Next hop type/IP、Source、Stateをセットで読む。

UDR resourceにrouteが存在してもNIC側でActiveになっていなければdata planeの根拠にならない。 BGP/peering/gateway change後のactual programmed state確認に有効。

destination-specificの最終判断はNetwork Watcher Next hopと組み合わせる。 VM/NICが完全にprovisionされていない等、effective route取得条件にも注意する。

通信や判断の流れを追う

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で証明する。

仕組み

control planeでVNet/peering/gateway/route tableが変更されるとAzure SDNがNIC contextへrouteをprogramする。

effective route tableはその合成結果を見るため、routing incidentのfirst-line evidenceとして使える。

ただしNVA内部route、guest OS route、application policyまでは示さない。Azure next hopの先は別証拠が必要。

Packet path

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

source NICを特定。
effective routesを取得しdestinationにmatchするprefixを抽出。
LPM/source/stateからwinner候補を確認。
Next hop toolでdestination-specific結果を照合。
NVA/guest/application側のdata planeへ進む。

設計判断

判断点	推奨	理由
Baseline	change前にJSON保存。	route incidentで「いつ変わったか」を比較可能。
Scope	問題を再現する正しいsource NICで取得。	別subnetのNICではroute setが違う。
Interpretation	SourceとStateを必ず表示。	prefix/next hopだけでは競合原因が分からない。
Limit	NVA内部routingの証明には使わない。	Azure SDNとappliance responsibilityを分離。

確認手順

Azure Portal

VM/NIC → Effective routesを開く。
route prefix/source/stateをfilterし、問題destinationのcandidateを確認。
Network Watcher 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 nic show-effective-route-table -g <rg> -n <nic> -o jsonc
az network nic show-effective-route-table -g <rg> -n <nic> -o table

PowerShell — read-only first

Get-AzNetworkInterface -ResourceGroupName <rg> -Name <nic>

障害切り分け

症状	疑う点	証拠	次の確認
UDRが見えない	route table未associate/別subnet	NIC subnet ID + routeTable ID	association修正
route stateがInvalid	next hop/peering/gateway state不整合	State/nextHop	control plane dependency確認
想定外BGP route	gateway/Route Server propagation	Source=BGP系	learned routes/propagation確認
effectiveは正常だが通信不可	NVA/NSG/guest/app層	Next hop + capture/log	次のlayerへ切り分け

変更時の確認と rollback

baseline route tableをticketへ添付。
change後にsame NIC/same destinationで再取得。
rollback後もroute stateがActiveへ戻ったことを確認。