Virtual Appliance Next Hop

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

Virtual Appliance Next Hopを理解するための前提

Virtual appliance UDRではnext hop private IPを指定する。next hopはAzureからdirect connectivityを持つ必要がある。 NVA NICはEnable IP forwardingを有効化し、guest OS/appliance側でもrouting/forwardingを有効にする。

NVAをtraffic sourceと同一subnetへ置き、そのsubnetのUDRで自分自身へ送るような構成はrouting loopを起こし得る。 InternetへforwardするNVAはproxyまたはSNAT等、source private IPをpublic egressへ適切に変換する必要がある。

HAはILB HA Ports、Gateway Load Balancer、Route Server BGP、vendor-native clustering等からfailure modelで選ぶ。 2026年にはAzure Virtual Network routing applianceというmanaged forwarding layerもGAしており、従来NVA/UDR designとの役割差をcurrent docsで評価する。

通信や判断の流れを追う

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

仕組み

Azure UDRが決めるのは「NVAのどのprivate IPへ渡すか」まで。NVA受信後のrouting table、policy、NAT、state syncはappliance責任。

Enable IP forwardingはAzure NICのsource/destination validationをforwarding use case向けに許可する設定であり、OS forwardingを自動enableしない。

HAでILB VIPをnext hopにする場合、probe healthとflow distribution/symmetryをvendor designに合わせる。BGP方式ではroute advertisement/withdrawalがfailover signalになる。

Packet path

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

source subnetでVirtualAppliance UDRを選択。
Azure SDNがnext-hop private IP/VIPへpacketを配送。
NVA NICで受信しvendor policy/routing/NATを実行。
NVA egress NICからnext networkへforward。
return trafficが同じstate domainへ戻るrouteを通る。

設計判断

判断点	推奨	理由
Placement	source workloadとNVAを同一subnetへ詰めない。	loopとpolicy couplingを避ける。
Forwarding	Azure NIC + OS/appliance両方を確認。	片方だけではdata plane fail。
HA	health signalとroute/flow steeringを一体設計。	instance failure時にblackholeしない。
NAT	north-south/east-west別にSNAT/DNAT pointを明示。	return pathとsource visibilityが変わる。

確認手順

Azure Portal

NIC → IP configurations / IP forwardingを確認。
Route table → Virtual appliance routeのnext hop IPを確認。
NVAのvendor health/route/policy + packet captureを確認。

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 -g <rg> -n <nva-nic> --query "{ipForwarding:enableIpForwarding,ipConfigs:ipConfigurations[].privateIPAddress}" -o jsonc
az network route-table route list -g <rg> --route-table-name <rt> -o table

PowerShell — read-only first

Get-AzNetworkInterface -ResourceGroupName <rg> -Name <nva-nic> | Select-Object Name,EnableIPForwarding,IpConfigurations

障害切り分け

症状	疑う点	証拠	次の確認
NVA IPへpacketが来ない	UDR/LPM/next hop invalid	effective route + Next hop	route association/direct reachability確認
NVAで受信するがforwardしない	OS/vendor forwarding/policy	NVA capture both sides	routing/policy修正
failover時blackhole	health/route withdrawal連携不足	probe/BGP/route state	HA design修正
TCPのみ不安定	asymmetry/state/NAT	bidirectional capture	return path/SNATを修正

変更時の確認と rollback

NVA変更前にroute/policy/NAT/session/health snapshot。
HA pairならtraffic drain/failoverを先に実施。
UDR切替はrepresentative 5-tupleとNext hopをbefore/after比較。
rollback後に両direction captureでsymmetry回復を確認。

What changed recently

2026年の運用上の注意

2026-08にAzure Virtual Network routing applianceがGA。managed forwarding layerという新しい選択肢が加わったため、大規模なUDR/NVA transitでは従来方式との比較対象にする。

Virtual Appliance Next Hop