System Routesを理解するための前提
Azureは各subnetにsystem routeを自動作成し、ユーザーはsystem route自体を削除できない。 VNet address spaceはVirtual network next hop、0.0.0.0/0はInternet、代表private rangesにはNone routeが初期配置される。
Peering、Virtual Network Gateway、service endpoint等を有効化するとoptional system routeが追加される。 UDRで一部system routeをoverrideできるが、service endpoint等にはpreferred routeとして特別な優先挙動がある。
route table resourceを見ただけではsystem/BGP/peering routeが見えないため、NIC effective routesを確認する。 None next hopはdropを意味し、未使用private rangeの誤送信を外へ出さない役割を持つ。
Control plane と data plane
仕組み
system routeはAzure SDNがcontrol planeから生成する。VNet address rangeを追加すると対応するVirtual network routeも変化する。
peeringを作るとremote address space向けVirtual network peering route、gatewayがrouteを学習するとVirtual network gateway routeがeffective stateへ加わる。
destinationごとのroute selectionはLPM→優先規則で行われる。System routeを単独で読むより、UDR/BGPを合成した結果を見る。
Packet path
routing問題は「どのresourceがあるか」ではなく、packetが各hopで何を選ぶかを順に追う。
- packet destination IPを確定。
- subnetにprogramされたsystem/UDR/BGP/peering routesを候補化。
- longest prefix matchを適用。
- 同一prefix候補のpriority/preferred route ruleを評価。
- selected next hopへforwardまたはNoneでdrop。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Read path | system route一覧ではなくNIC effective routesを基準にする。 | runtimeに近いprogrammed stateを確認できる。 |
| Override | UDR投入前に既存optional/preferred routeを確認。 | 意図せぬPaaS/gateway path変更を防ぐ。 |
| Private ranges | None routeとVNet address rangeの関係を理解。 | 「RFC1918だから自動でVNet内へ行く」と誤認しない。 |
| Change | VNet address space/peering/gateway change後にeffective stateを再取得。 | control-plane changeがrouteへ反映されたことを証明。 |
確認手順
Azure Portal
- NIC → Effective routesでSource/Address prefix/Next hop type/Stateを確認。
- VNet/Peering/Gateway設定と照合。
- destination-specificにはNetwork Watcher Next hopを併用。
Verification discipline
- subscription / resource group / resource IDを記録する。
- 同じsource・destinationでbefore/afterを比較する。
- read-only evidenceを保存してから変更する。
- control-plane successとapplication successを別々に判定する。
az network nic show-effective-route-table -g <rg> -n <nic> -o table
az network route-table list -g <rg> -o tableGet-AzNetworkInterface -ResourceGroupName <rg> -Name <nic>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| 0/0がInternetに見える | system defaultが残っている | effective routeのよりspecific/UDR有無 | selected routeをdestination単位で確認 |
| private prefixがNone | VNet address space/BGP/UDRに該当routeなし | effective route | 必要なprefixを正しいsourceから導入 |
| Peering後にrouteがない | peering未成立/sync不足 | peering state | 両方向 peering/sync確認 |
| PaaSだけ想定routeを無視 | service endpoint preferred route | effective route next hop type | service endpoint設計を確認 |
変更時の確認と rollback
- system route自体はrollback対象ではなく、それを変化させたpeering/VNet/gateway/service settingを戻す。
- change前後のeffective route diffを保存。
- None/Internet next hop変更はcritical flowをnew connectionで再試験。