Virtual WAN Hub Routingを理解するための前提
Virtual Hub routingでは各connectionが1つのroute tableへassociateし、自身のroutesを1つ以上のroute tables/labelsへpropagateする。 associationとpropagationは逆方向の概念ではなく、前者がpacket lookup context、後者がroute distribution先を決める。
Default route tableは標準transitに使われ、None route tableやcustom tablesでsegmentationを構成できる。 static routesをconnection/hub tableへ追加する場合、next hop connectionとdestination prefixを明示し、propagated routeとの競合を確認する。
route mapsを使うとroute filtering/aggregationやAS-PATH/community操作など、connection境界のadvertisement制御が可能。適用対象とlimitationsをcurrent docsで確認する。 route tableの表示にprefixがあるだけではdestination側return routeを保証しない。双方向のassociated tableとpropagationを確認する。
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側経路を証明できない。
仕組み
Default tableへの全propagationはfull-transitを作りやすい。isolation要件があるdomainはcustom table/None/labelsで明示的に分離する。
labelは複数hub/route tableへのlogical propagation targetとして便利だが、同名labelの影響範囲をinventory化する。
static routeはpropagated/BGP routeとのmore-specific競合を起こせる。追加前にsource/destination両方向のcandidate routesを確認する。
route mapはrouting policyをAzure側へ持ち込めるが、過度なAS-PATH/community manipulationはon-prem policyとの相互依存を増やす。
hub routing preferenceとExpressRoute/VPN同prefix競合を含め、どのroute sourceが選ばれるかchange前後で検証する。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- source connectionのpacketがvirtual hub routerへ入る。
- そのconnectionにassociatedされたroute tableでlongest-prefix/best routeを解決する。
- routeのnext hop connectionまたはsecurity solutionへ転送する。
- routeがremote hubへpropagateされていればinter-hub transitでdestination hubへ進む。
- destination側connectionへpacketを出し、replyはdestination connectionのassociated tableで独立にroute lookupされる。
- 非対称障害ではforward側tableとreturn側tableを別々にdumpし、同一prefixのsource/next hopを比較する。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Association matrix | Connection × associated tableを一覧化する。packet lookupに使うtableをsourceごとに固定する。 |
| Propagation matrix | Connection prefix × destination tables/labelsを一覧化し、必要/不要reachabilityをレビューする。 |
| Route source | static/propagated/intent/route map後のprefixを区別し、同一prefix競合時のbest routeを確認する。 |
| Return path | destination connectionからsource prefixが見えるtableを確認し、片方向だけのreachabilityを防ぐ。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Full transit | 共通Default tableへassociate/propagateする。 | branch/VNet全相互接続が要件ならsimpleで運用しやすい。 |
| Isolation | custom route tables + scoped propagation/labelsでdomain分離する。 | security boundaryをrouting layerでも明示できる。 |
| Shared services | consumer tablesへshared prefixだけpropagateし、不要なeast-westを公開しない。 | segmentationと共通service accessを両立する。 |
| Route maps | 大量prefix/filter/aggregation要件がある接続で限定採用する。 | 手動static routeよりpolicy化できるが、複雑性を増やすため用途を限定する。 |
確認手順
Azure Portal / provider / edge
- Virtual Hub → Route tablesでtable/label/static routesを確認する。
- 各VNet/branch/ER connectionでAssociated route tableとPropagate to route tables/labelsを確認する。
- source/destination両側のeffective/propagated routesを取得し、route matrixと比較する。
- 変更後は代表prefixごとのbidirectional flowを実行し、security appliance logも必要に応じ確認する。
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 route-table list -g <rg> --vhub-name <hub> -o table
az network vhub route-table show -g <rg> --vhub-name <hub> -n <route-table> -o jsonc
az network vhub route-table route list -g <rg> --vhub-name <hub> -n <route-table> -o table
az network vhub connection list -g <rg> --vhub-name <hub> -o jsoncGet-AzVirtualHub -ResourceGroupName <rg> -Name <hub>
# Az.NetworkのVirtual Hub route table / connection cmdletsでassociation・propagationをread-only取得する。障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| sourceからだけ届く | destination側source prefix未propagate/association差 | 両connectionのroute tables | return tableを独立に確認する |
| 新route追加で別segment障害 | more-specific static route/label blast radius | before/after route dump | 新routeのprefixとnext hopを全tableで検索する |
| ERとVPNでpathが揺れる | hub routing preference/BGP attribute/route map | route source + AS path + selected next hop | 同prefixの全candidate routeを比較する |
| isolated segmentが繋がる | Default propagation/label誤設定 | propagation matrix | security ACLだけでなくrouting leakを修正する |
変更時の確認と rollback
- association/propagation変更前に全connectionのmatrixとroute table JSONを保存する。
- 1 connectionずつ変更し、expected added/removed prefixesを機械的にdiffする。
- static route/route map rollbackは元prefixだけでなくroute source/AS attributesまで戻す。
- rollback後は双方向flowとsegmentation negative testの両方を実施する。