ExpressRoute Virtual Network Gatewayを理解するための前提
ExpressRoute virtual network gatewayはExpressRoute circuitとVNetを接続し、route exchangeと通常data pathを仲介する。Circuit resourceだけではVNet接続にならない。 gatewayはGatewaySubnetへ配置され、SKUによりperformance/scale/featureが異なる。circuit bandwidthだけでend-to-end capacityを見積もらない。
zone-redundant ErGw*AZ系やErGwScale等、current SKU/scale modelを選び、古いSKU名を新規architectureへ固定しない。 FastPathを使う場合でもgatewayはroute exchangeのため必要。FastPathは「gateway resource不要」機能ではない。
VNet peeringのgateway transitではhub側Allow gateway transitとspoke側Use remote gatewaysを正しく組み合わせ、spoke effective routesで伝播を検証する。 Private Endpoint等一部destinationやmaintenance条件ではFastPath対応可否/経路が異なるため、data pathをresource typeごとに確認する。
Control plane と data plane
Provider / responsibility boundary
ExpressRoute circuit、peering、MSEE側BGP、VNet gateway / FastPath、Azure route propagationを管理する。
customer edgeからMicrosoft edgeまでのL2/L3 service、cross-connect、VLAN等を担当する。provider provisioningはAzure resource stateと別に追う。
CE routerのBGP policy、local preference / AS path、prefix filter、冗長回線を管理する。片系だけ正常でもend-to-end冗長性は成立しない。
仕組み
gateway SKUはthroughputだけでなくroute scale、VNet connection数、FastPath eligibility、zone redundancy要件で選ぶ。
GatewaySubnetはgateway infrastructure専用として十分なaddress spaceを確保し、UDR/NSG等はcurrent support guidanceを確認して慎重に適用する。
複数VNetを同circuitへ接続する場合、各connection resourceとgateway capacityをinventory化し、1つのconnection failureをcircuit全体障害と誤認しない。
gateway transitでspokeへon-prem routeを配布する場合、peering flagだけでなくspoke NICのeffective routeとon-prem return advertisementを確認する。
FastPath fallback時はtrafficがgateway data pathへ戻るため、fallbackを含むgateway capacity/availabilityを考慮する。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- circuit private peeringでon-prem/Azure routeがMSEEへ存在する。
- VNet gateway connectionがcircuitとVNet gatewayを論理接続する。
- gatewayがlearned routesをVNet routingへ伝播し、subnet/NIC effective routesへ反映する。
- 通常data flowはgateway data pathを経由しdestination NICへ向かう。FastPath eligibleならMSEEから直接VNet dataplaneへ進む。
- spokeがUse remote gatewaysを設定していればhub gateway由来routeがpeering transitを通じてspokeへ反映される。
- replyはspoke/hub effective route→gateway/FastPath→MSEE→CEへ戻り、on-prem route/FW policyで完結する。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Gateway learned/propagated | gateway connectionとVNet/spoke effective routeを比較し、on-prem prefixがどこまで伝播したか確認する。 |
| Gateway transit | hub AllowGatewayTransit / spoke UseRemoteGatewaysとspoke effective routeをセットで確認する。flagだけを証拠にしない。 |
| UDR conflict | subnet UDRでVirtualAppliance等がmore-specificに選ばれる場合、ExpressRoute gateway routeより優先されるためforward/returnを追う。 |
| FastPath fallback | eligible/non-eligible destinationとfallback時のroute/metricを区別し、gateway performanceがfallback trafficを処理できることを確認する。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| SKU | route scale・throughput・FastPath・AZ要件の最大値から選定する。 | 接続後のtraffic増やroute増でgatewayだけがbottleneckになるのを防ぐ。 |
| Zone redundancy | region/criticalityが求める場合はAZ対応gatewayを採用する。 | circuit/peering冗長とは別のVNet attachment failure domainを減らす。 |
| Transit | shared hub gatewayを使うspokeはpeering/UDR/DNS/security設計を標準化する。 | spokeごとの例外がroute asymmetryを生みやすい。 |
| FastPath | latency/throughput要件とsupport matrixが合う場合に有効化する。 | 全trafficが常にgateway bypassするとは限らずfallbackを考慮する必要がある。 |
確認手順
Azure Portal / provider / edge
- Virtual network gateway → Overview/ConfigurationでGateway type=ExpressRoute、SKU、GatewaySubnet、zone、provisioningを確認する。
- Connectionsで対象ExpressRoute circuit connection、Connection status、FastPathを確認する。
- hub/spoke peeringでgateway transit flagsを確認し、spoke NIC Effective routesを採取する。
- gateway metricsとcircuit/provider metricsを分け、bottleneck locationを推測で決めない。
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 vnet-gateway show -g <rg> -n <er-gateway> -o jsonc
az network vpn-connection list -g <rg> -o table
az network nic show-effective-route-table -g <rg> -n <nic> -o tableGet-AzVirtualNetworkGateway -ResourceGroupName <rg> -Name <er-gateway>
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName <rg>
Get-AzEffectiveRouteTable -NetworkInterfaceName <nic> -ResourceGroupName <rg>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| Circuit/BGP正常だが1 VNet不可 | VNet gateway connection/gateway state | connection + gateway + effective route | providerへescalateする前にVNet attachmentを確認する |
| spokeだけon-prem不可 | gateway transit flag/UDR/return advertisement | peering + spoke effective routes | hub成功をspoke成功とみなさない |
| FastPath有効後も一部だけgateway経由 | destination/support matrix/fallback | destination type + metrics/path | FastPathのeligible scopeを確認する |
| traffic増でloss | gateway SKU/capacityかprovider/circuitか | gateway metric + circuit metric + CE interface | bottleneckをlayer別に切り分ける |
変更時の確認と rollback
- 変更前にgateway JSON、connections、peering flags、spoke effective routes、metrics baselineを保存する。
- SKU/scale変更はmaintenance impactとFastPath eligibilityを確認して実施する。
- gateway transit変更はspokeごとにroute diffとreturn pathを確認して段階適用する。
- rollback後はconnection stateだけでなくhub/spoke両方のeffective routeとtrafficを再試験する。
What changed recently
current gateway guidanceにはErGwScaleを含むscale modelとFastPath要件が反映されています。既存gatewayはSKU名だけを見ず、route scale、実traffic、FastPath/fallback、zone redundancyを含めて再評価します。