Virtual WAN Virtual Hubを理解するための前提
Virtual hubはVirtual WAN内のregion単位Microsoft-managed virtual network/router containerで、customerが通常VNetのsubnet/NICとして管理するものではない。 hubにVPN/ExpressRoute/P2S gateways、Azure Firewall/NVA、VNet connections等を関連付け、branch/user/on-prem/spoke transitを集約する。
Standard virtual hub routerはconnections間routingをBGP/managed route tablesで処理し、hub routing capacity/scaleを監視する。 複数hubはStandard Virtual WANでfull mesh transitを形成できるが、route table segmentation/routing intentによりreachabilityはpolicyで変わる。
hub自体のstate、router state、gateway state、connection stateは別々に監視し、Virtual WAN resourceが存在するだけで接続正常と判定しない。 hub region failureに備える場合は別region hub/branch path/ER-VPN designを持ち、接続先が実際にalternate hubへrouteできることを試験する。
Control plane と data plane
Provider / responsibility boundary
Virtual WAN、virtual hub、connections、route tables、routing intent / route map等を管理する。
Microsoft-managed virtual hub router / gatewaysがbranch・ER・P2S・VNet間のtransitを処理する。通常のcustomer-managed hub VNetとは運用モデルが異なる。
SD-WAN controller、CPE、ER provider、remote userなど外側のfailure domain。Azure側connection stateだけではbranch側経路を証明できない。
仕組み
hub address prefixはhub infrastructure用で、spoke workload address spaceとして使わない。将来gateway/security service追加を含むcurrent sizing guidanceを確認する。
hubに複数gateway/serviceを置いても、それぞれのconnection/prefixが自動的に全segmentへ到達するとは限らない。route table policyが決める。
virtual hub routing infrastructure units/capacity指標をmonitorし、大規模spoke/branchでrouter scaleを可視化する。
hub routing preferenceはExpressRoute/VPN/AS Path等の複数route sourceが競合する環境で重要。設定変更は全hub transitへ影響し得る。
secure virtual hub化する場合、Azure Firewall/NVA/routing intentとDNS/private access設計を一体で確認する。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- source connectionからhub routerへpacketが到達する。
- associated hub route tableでdestination prefixのbest routeを選択する。
- next hopが同hub VNet/branch/ER/P2Sなら該当connectionへ転送する。
- remote hub prefixならinter-hub transitを通りdestination hub routerへ進む。
- routing intent/security policyがあれば指定inspection hopへsteerする。
- destination connectionへ出た後のreturn trafficもsource prefixへのrouteを持ち、stateful pathが成立する必要がある。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Hub table | Default/custom tablesにlocal/remote connection prefixがどのsourceで載るか確認する。 |
| Connection propagation | branch/VNet/ER routeが期待tableへpropagateし、None/isolated tableへ漏れていないか確認する。 |
| Inter-hub | remote hub routesが見えることと実connection healthを両側で確認する。 |
| Capacity | routing infrastructure/connection scale metricsとroute countをbaseline化し、performance issueをsecurity問題と誤認しない。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Region | workload/branch latencyとregional failure domainでhub placementを決める。 | 単一central hubへの過集中を避ける。 |
| Segmentation | connectionごとのassociation/propagationをtemplate化する。 | 手作業のlabel/table差分はreachability事故を生みやすい。 |
| Gateways | VPN/ER/P2Sのcapacity/scaleは各gateway settingで別設計する。 | hub router healthyでもgateway bottleneckは起こり得る。 |
| DR | alternate hubへbranch/VNetが接続・routeできるか実failoverを行う。 | 別region hubが存在するだけではRTOを証明しない。 |
確認手順
Azure Portal / provider / edge
- Virtual WAN → Virtual hubsでregion/address/stateを確認する。
- Virtual hub Overview/Routesでrouter state、route tables、effective routesを確認する。
- VPN/ExpressRoute/P2S gatewaysとVNet connectionsをconnection typeごとに確認する。
- Azure Monitor metricsでhub data processed、routing infrastructure units等のcurrent supported metricsを確認する。
Verification discipline
- subscription / resource group / resource ID / region / connection名を固定し、同名resourceの取り違えを防ぐ。
- control-planeのProvisioningStateだけで完了判定せず、peer/session/route/metricと実packetの結果を別々に保存する。
- advertised route・learned route・effective routeを混同しない。各段階で「誰が誰へ何を広告し、最終的にどのFIBへ入ったか」を確認する。
- 変更前後で同一source/destination/protocolを再試験し、既存sessionの継続を新規flowの成功と誤認しない。
az network vhub show -g <rg> -n <hub> -o jsonc
az network vhub route-table list -g <rg> --vhub-name <hub> -o table
az network vhub connection list -g <rg> --vhub-name <hub> -o table
az monitor metrics list-definitions --resource <vhub-resource-id> -o tableGet-AzVirtualHub -ResourceGroupName <rg> -Name <hub>
Get-AzMetricDefinition -ResourceId <vhub-resource-id>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| hub upだが特定connection不可 | connection/gateway/route propagation | connection state + hub routes | hub aggregate healthからconnectionへ掘る |
| remote hubだけ不可 | inter-hub route/policy | source/dest hub route tables | 両hubでprefix visibilityを比較する |
| 大量接続時に性能低下 | hub/gateway capacity/scale | routing units、data processed、gateway metrics | security deviceだけを疑わずmanaged routing capacityも確認する |
| 新spokeが意図せず全到達 | Default propagation/label | connection association/propagation | segmentation templateとの差分を修正する |
変更時の確認と rollback
- hub変更前にresource JSON、route tables、connections、gateways、metrics baselineを保存する。
- route policy変更はhub単位のblast radiusを見積もり、限定connectionで検証する。
- gateway/service削除はdependent connectionsを確認し、traffic代替pathを先に成立させる。
- rollback後はlocal/remote hubの代表flowとroute propagationを再確認する。