Virtual Network Peeringを理解するための前提
Peeringは双方向の関係で、各VNet側にpeering linkが必要。片側だけならInitiated等の未成立状態になり得る。 peeringはnontransitive。Spoke A↔HubとHub↔Spoke BだけでA↔Bが自動routingされるわけではない。
Allow forwarded trafficは転送packetをpeeringで受ける許可であり、UDRやNVAそのものを作成しない。 Allow gateway/route server transitとUse remote gateway/route serverはhybrid connectivity共有のための対になる設定。
remote gatewayの利用は同一VNet内で制約があり、既にlocal gatewayがあるVNetでは使えない等の条件を確認する。 VNet address spaceを変更した後はpeering側のaddress space syncが必要になる場合がある。
Control plane と data plane
仕組み
peeringはVNet address prefixを互いのeffective routing stateへ追加し、trafficはMicrosoft backboneを通る。
Hub-SpokeでNVA transitを実現するには、spokeのUDRでNVAをnext hopにし、peering側でforwarded trafficを許可するなど複数要素が必要。
gateway transitはhub gateway/Route Server由来のreachabilityをspokeへ共有するcontrol-plane設定。data planeが通るかはUDR/BGP/security/return pathも確認する。
address space resize後にsyncが不十分だと新prefixのreachabilityがpeeringに反映されない。
Packet path
routing問題は「どのresourceがあるか」ではなく、packetが各hopで何を選ぶかを順に追う。
- source NICがdestination prefixに対しVirtualNetworkPeering routeを選択。
- source側NSG/UDR等を通過。
- Microsoft backboneでpeered VNetへ転送。
- destination側peering/security/route contextで受信。
- return pathもdestination VNetから独立にroute selection。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Topology | direct peeringかHub transitかを先に決める。 | nontransitive性を前提にrouteを設計。 |
| Forwarded traffic | NVA/gateway等がthird-party sourceを転送する方向だけ明示許可。 | 「Allow forwarded trafficだけでtransit完成」と誤認しない。 |
| Gateway transit | hub側transit allow、spoke側remote gateway useを対でreview。 | 片側設定漏れを防ぐ。 |
| Resize | address space変更後にpeering syncをchange procedureへ入れる。 | 新prefixだけ不達になる事故を防ぐ。 |
確認手順
Azure Portal
- Virtual networks → Peerings → 両方向のPeering statusを確認。
- Traffic to remote virtual network / Forwarded traffic / Gateway or route server transit settingsを両側で確認。
- address space変更後はSync status/actionを確認し、effective routesで新prefixを検証。
Verification discipline
- subscription / resource group / resource IDを記録する。
- 同じsource・destinationでbefore/afterを比較する。
- read-only evidenceを保存してから変更する。
- control-plane successとapplication successを別々に判定する。
az network vnet peering list -g <rg> --vnet-name <vnet> -o table
az network vnet peering show -g <rg> --vnet-name <vnet> -n <peering> -o jsonc
az network vnet peering sync -g <rg> --vnet-name <vnet> -n <peering>Get-AzVirtualNetworkPeering -ResourceGroupName <rg> -VirtualNetworkName <vnet>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| state=Initiated | 片側peeringのみ | 両VNet peering一覧 | reciprocal peeringを作成 |
| spoke-to-spoke不達 | nontransitiveを見落とし | effective routes | direct peering/VNA/Virtual WAN等のtransit設計 |
| NVA経由だけ不達 | forwarded traffic/UDR/IP forwarding不足 | peering flags + effective route + NVA capture | 3要素を分離確認 |
| VNet拡張後に新CIDRだけ不達 | peering address space未sync | peering sync state/effective route | 両方向sync後に再検証 |
変更時の確認と rollback
- 変更前に両側peering JSONとeffective routeを保存。
- gateway transit変更はon-prem prefix reachabilityとreturn routeを同時に確認。
- forwarded traffic変更はNVA bypass pathがないことをtest。
- rollbackは両方向の設定を元に戻し、route convergence後にnew connectionで再試験。
What changed recently
VNet address space resize後のpeering syncを運用手順へ明示する。resize自体の成功と、peered VNetから新prefixへ到達できることは別の完了条件。