Azure ExpressRouteを理解するための前提
ExpressRouteはconnectivity provider等を介したprivate connectionでon-premises networkをMicrosoft cloudへ拡張する。VPN Gatewayのようにpublic Internet上へIPsec tunnelを張るserviceではない。 ExpressRoute circuit、Azure private peering、VNet gateway connectionは別resource/lifecycle。CircuitがProvisionedでもVNetへのdata pathが完成しているとは限らない。
routing exchangeはeBGPで行い、private peeringではMicrosoft edgeとのprimary/secondary BGP sessionを両方成立させて冗長性を確保する。 provider edge、Microsoft Enterprise Edge(MSEE)、ExpressRoute gateway/FastPath、Azure VNet routingを別failure domainとして監視する。
Microsoftはmaximum resiliencyとして異なるpeering locationの2 circuitsへの接続を推奨している。single circuitは同一location内の二重化に留まる。 stateful firewall/NVAを経由する設計では複数ExpressRoute pathやVPN backupが非対称routingを生み得るため、forward/returnのpath controlを明文化する。
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冗長性は成立しない。
仕組み
Circuitは「専用線そのもの」だけではなくAzure上の論理resource。service keyをproviderへ渡し、provider provisioningとAzure circuit stateの双方が完了して初めてpeeringへ進む。
Azure private peeringはVNet/private workload用のrouting domain。Microsoft peeringとはprefix、NAT、route filter、用途が異なるため混同しない。
primary/secondary linkで同一prefixを交換し、片link maintenanceでもsession/trafficを残せるようCE側のrouting policyを設計する。
VNet接続ではExpressRoute virtual network gatewayのSKU/capacity/zone redundancyと、connection objectの状態を別々に確認する。
DRではsecond circuit/location、VPN backup、Global Reach等を組み合わせられるが、path preferenceを明示しないとstateful deviceでasymmetryが起きる。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- on-prem workloadがAzure prefix宛packetをCE routerへ送り、CEのBGP/FIBがExpressRoute provider pathを選ぶ。
- provider networkがpacketをMicrosoft Enterprise Edgeへ運び、private peeringでMicrosoft側へ引き渡す。
- Microsoft backbone上で対象region/VNet接続へ転送される。
- 通常pathではExpressRoute virtual network gatewayを介してVNet routeへ入り、FastPath有効・対応destinationならgateway data pathをbypassする。
- Azure workloadへ到達後、replyはAzure routing/BGP advertisementに基づきExpressRouteへ戻る。
- 複数circuit/VPN pathがある場合はforwardとreturnが異なるedgeを通る可能性を確認し、stateful inspectionのdropを防ぐ。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Customer advertisements | CEからprivate peeringへ広告するon-prem prefixをfilter/aggregateし、prefix limitと意図しないroute leakを管理する。 |
| Microsoft advertisements | CEが受信したAzure VNet prefixとnext hop/AS pathを確認し、secondary linkにも同等のrouteがあるか比較する。 |
| Azure effective route | VNet NICでVirtualNetworkGateway由来のrouteとUDR等の競合を確認する。Circuit route tableだけではworkload forwardingを証明しない。 |
| Failure convergence | primary link/circuit/location停止時にBGP withdrawalとbest pathがどこへ移るか測定し、application sessionへの影響まで記録する。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Resiliency | critical workloadは異なるpeering locationの2 circuitsを基準に検討する。 | single circuitのlocal redundancyだけではlocation/provider-wide failureを吸収できない。 |
| Provider | 帯域・locationだけでなくdiverse last-mile/CE/colo pathを確認する。 | Azure側二重化とprovider側物理diversityは別問題。 |
| Gateway | VNet gateway SKUはroute scale/throughput/connection要件とFastPath requirementで選ぶ。 | circuit bandwidthだけ増やしてもgateway bottleneckが残り得る。 |
| Backup path | S2S VPN併用時はnormal/failed stateのroute preferenceを設計・実測する。 | backupが存在するだけでは自動的に期待pathへ収束しない。 |
確認手順
Azure Portal / provider / edge
- ExpressRoute circuit → OverviewでProvider status、Circuit status、bandwidth、SKU、peering locationを確認する。
- Peerings → Azure private peeringでprimary/secondary BGP、VLAN/ASN、route table/ARPのevidenceを確認する。
- Virtual network gateway/Connectionsで対象VNetとのconnection state、gateway SKU、FastPath設定を確認する。
- Connection Monitor/Network Watcherとon-prem router telemetryでloss/latency/route changeを両側から観測する。
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 express-route show -g <rg> -n <circuit> -o jsonc
az network express-route peering list -g <rg> --circuit-name <circuit> -o table
az network vnet-gateway show -g <rg> -n <er-gateway> -o jsonc
az network vpn-connection list -g <rg> -o tableGet-AzExpressRouteCircuit -ResourceGroupName <rg> -Name <circuit>
Get-AzExpressRouteCircuitPeeringConfig -ExpressRouteCircuit <circuit-object>
Get-AzVirtualNetworkGateway -ResourceGroupName <rg> -Name <er-gateway>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| Circuit EnabledだがBGP down | provider provisioning、VLAN/peer IP/ASN、cross-connect | provider status + primary/secondary peering state | Azure VNet routingより先にL2/BGP boundaryを確定する |
| BGP upだがAzure VM不可 | VNet gateway connection、gateway route、UDR/NSG | connection state + effective route | circuitとVNet attachmentを別layerとして確認する |
| 片系maintenanceで断 | secondary BGP未成立/route差、single CE/provider path | primary/secondary route tableとCE config | 冗長link両方を平常時からactiveに検証する |
| VPN backupへ切替後だけFW drop | 非対称return、route preference差 | 両方向traceroute/route/FW session log | stateful middleboxを跨ぐforward/return pathを揃える |
変更時の確認と rollback
- 変更前にcircuit/provider status、peerings、route tables、gateway connections、CE BGP configを保存する。
- peering policy変更はprimary/secondaryを一度に壊さず、片系で検証してから反映する。
- second circuit/backup pathを外すrollbackでは元のroute preferenceをCE/Azure両側で復元する。
- rollback後はBGP upだけでなく代表prefixの双方向trafficと片link failoverを再確認する。
What changed recently
2026年のcurrent PortalではresiliencyをMaximum / High / Standardとして設計時に意識させる導線が強化されています。新規critical設計はsingle circuit前提をdefaultにせず、異なるphysical peering locationを含むfailure domainから選定します。