Route Selection / Longest Prefix Match

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

Route Selection / Longest Prefix Matchを理解するための前提

最初の原則はlongest prefix match。10.10.1.0/24は10.10.0.0/16や0.0.0.0/0より優先。同一prefixで複数candidateがある場合、一般にUDR > BGP > Systemのpriority。

ただしVirtual network、Virtual network peering、VirtualNetworkServiceEndpoint等のpreferred system routeには特別な優先挙動があるため、単純な3段階だけで断定しない。 route selectionはsource subnet/NICのcontextで行われ、return directionでは別のroute setが使われる。

selected routeはeffective routesとNetwork Watcher Next hopでdestination単位に実証する。 route stateがInvalid等の場合はcandidateに見えても実trafficで使われないためStateも確認する。

通信や判断の流れを追う

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

仕組み

例: 0.0.0.0/0→Firewall UDR、10.20.0.0/16→Peering、10.20.30.0/24→別NVA UDRがある場合、10.20.30.5は/24 UDRが選ばれる。

同じprefixのBGPとUDRが競合する場合はUDRが優先されるのが基本。ただしservice endpointなどpreferred routeは別扱い。

routing loopは往路だけのLPM表では見えない。各hopで同じdestinationに対するnext hopを追い、return destinationについて逆方向も追う。

Packet path

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

destination IPにmatchする全prefixを列挙。
最長prefix lengthのcandidateだけ残す。
same-prefixならsource priority/preferred route ruleを評価。
route state/next hop reachabilityを確認。
selected next hop後の次hopでも同じ作業を繰り返す。

設計判断

判断点	推奨	理由
Review order	Prefix length → source → state → next-hop healthの順に見る。	route tableの並び順や名前に惑わされない。
0/0	catch-allとして扱い、specific routeが勝つ前提で設計。	forced tunnelingを過信しない。
Return path	reverse destinationで同じ計算を行う。	stateful NVAのasymmetryを検出。
Evidence	effective routes + Next hopを保存。	「設定上そう見える」をdata plane判定へ近づける。

確認手順

Azure Portal

NIC → Effective routesをAddress prefixで確認。
Network Watcher → Next hopでdestination IPを指定。
UDR/BGP/Peering sourceをroute matrixへ書き出す。

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 table

PowerShell — read-only first

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

障害切り分け

症状	疑う点	証拠	次の確認
0/0のNVAへ行かない	よりspecific routeが存在	effective routes	LPMでwinnerを特定
BGPがUDRに負ける	same-prefix priority	route source	意図なら正常、違うならUDR変更
service endpointだけ別path	preferred route behavior	effective next hop type	service endpointを考慮
往路正常/復路drop	reverse route winnerが異なる	reverse effective routes/capture	symmetry修正

変更時の確認と rollback

route changeはwinnerが変わるdestination setを事前計算。
before/after effective routeをprefix単位でdiff。
rollback後もnew connectionでreturn pathを含め再確認。

Route Selection / Longest Prefix Match